I have always considered this a bad practice, although it's true it's not a big issue because any software that depends for something important on dates is mostly gonna work using a reliable source to get the date, on the rare situations this would happen I think it could be a potential security risk.

That a user needs to change date can happen from time to time, which looks totally insecure is allowing for example to set as system date one from the year 2000 in a system that runs Windows 10.

Why is something like this allowed even though it may have some security risks?

  • 1
    the computer's date can be set outside of the OS, so it's literally not their business.
    – dandavis
    Jun 1, 2017 at 2:57

3 Answers 3


Because there can be numerous good reasons to force a system date at an old value or in the opposite in the future. And an OS vendor that would implement a feature forbidding to set a date older than the one of the OS release would unplease his customers!

You may have to re-run old programs with old values to build again reports from example if the original report is no longer available but you still have the original values. Some programs were clever enough to accept a month as input and use automatically the year corresponding at the 12 last months. Or do not ask for any date and automatically use previous month - expected to be run on a monthly base from a cron. Ok, the program should be re-written to allow entering a date. But re-writing of old programs comes at a rather high cost (need to find programmers able to understand old dialects, need to find old compilers or port the whole code to a new version of the language), while changing a date is a trivially simple operation. Ok it is just a workaround but it is a simple and sufficient one for use cases like that.

A real use case I have seen was a workaround to keep old applications that used to store the date in only 2 digits. In fact they could only accept dates in the range 1970 (origine of most dates in system format) and 1999. Only 30 years available. The trick was a calendar has a period of 28 years (bissextile * day of first of january). We were glad in to 2000' to be able to declare to the stupid computer hosting the stupid app that the year was actually in the 70'...

Anyway changing the date is an administrative task (in the sense requiring administrator priviledges). So a normal user should not be able to do it. And administrative priviledges include really dangerous operations such as formatting a disk full of data. Or erasing the boot sector from a system disk. Or [write here the most stupid action your imagine on a computer]. And there are indeed correct use cases for them such as re-using an old disk.

That's the reason why a system normally trust his admin, whatever he asks for. There are indeed warnings more or less saying Hey admin, this looks a really weird and dangerous thing! Are you sure you really want it???. But as for almost any stupid action an acceptable use case can be found, the system just obeys.


In short I suspect it's allowed because the OS developers have never stopped that ability. The protection offered by changing dates to wildly inaccurate times may offer protection to some attacks. Although I suspect the potential threat is too low to justify the need to 'fix' the 'vulnerability'.

I suspect many real world attacks such as manipulating authentication protocols is done using a relatively small window of time adjustment - this would be difficult therefore to protect against without causing negative impacts on legitimate processes.


How would computer can recognize what is the date and you are setting something insecure, i.e. if you are offline? Or how you would like to limit it? Something like since the date of the OS release to when? Or since some patch release?

Setting of the date is usually protected and only administrators can change it (or trustworthy ntp server). So I don't see any reason why to limit this.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .