I wanted to check how a certain software reacts when I change my computer's date. But I could not change the system time to anything less than 1970. Why is that?

  • 9
    Time counts seconds from 1jan1970 00:00:00 (epoch), so you'd need a negative number of seconds, and the second counter is a positive value (unsigned)
    – guiverc
    Mar 6, 2020 at 22:02
  • This is a massive interoperability problem for Amiga users, whose epoch is January 1st, 1978. Mar 7, 2020 at 8:10
  • Are you trying to bypass license restrictions by setting the date back? So, you want to run a software in trial mode that expires in 1970? Mar 8, 2020 at 16:01
  • 1
    Can I ask why you want the date set prior to 1970? Just curious.
    – B-K
    Mar 9, 2020 at 1:47
  • 1
    Out of curiosity, what tools did you try for setting the time? The answers are correct that 1st Jan 1970 is represented as zero, but it is both possible and common to represent earlier dates using a signed integer, so I'm curious where the limitation in this case is being imposed.
    – IMSoP
    Mar 9, 2020 at 12:37

3 Answers 3


UNIX and POSIX-compliant systems encode system time ("Unix time") as the number of seconds elapsed since the start of the Unix epoch at 1 January 1970 00:00:00 UTC, excepting leap seconds which are not counted. The limitation was inherited from UNIX. 32-bit values meant, to get a reasonable degree of precision, Day Zero had to be pretty close, so that precluded going back to 0 A.D., or, more reasonably, 5780 years and change, since the date of this answer is 10 Adar 5780 {g}.

  • 14
    It's signed 32-bit though, so it should (and in most cases does) work back to late 1901.
    – hobbs
    Mar 7, 2020 at 4:49
  • 7
    Using 1970 allows it to reach 2038 with a 32-bit signed int.
    – ikegami
    Mar 7, 2020 at 5:20
  • 3
    Just a note that this definition is slightly incorrect since Unix time does not count leap seconds. Hence there have been more seconds than what Unix time would suggest there has been since Jan 1, 1970. Mar 9, 2020 at 1:00
  • 1
    @Sandy Chapman TY for pointing to an issue which needed documenting.
    – K7AAY
    Mar 9, 2020 at 1:45
  • 1
    10 Adar 5780 is the date you wrote this answer, not 0AD. That last sentence is really ambiguous.
    – J...
    Mar 9, 2020 at 13:57

From the wikipedia:

Unix time (also known as Epoch time, POSIX time, seconds since the Epoch, or UNIX Epoch time) is a system for describing a point in time. It is the number of seconds that have elapsed since the Unix epoch, that is the time 00:00:00 UTC on 1 January 1970, minus leap seconds.

Also an explanation:

Linux is following the tradition set by Unix of counting time in seconds since its official "birthday," -- called "epoch" in computing terms -- which is Jan. 1, 1970.

A more complete explanation can be found in this Wired News article. It explains that the early Unix engineers picked that date arbitrarily, because they needed to set a uniform date for the start of time, and New Year's Day, 1970, seemed most convenient.

  • 1
    I don't think this really explains the limitations. Many systems use the Unix epoch internally, but with a signed integer so that representing earlier dates is not a problem. If storing timestamps in unsigned integers was common, the 2038 problem would instead be "the 2106 problem".
    – IMSoP
    Mar 9, 2020 at 12:43

On a UNIX (and Linux) system, the counter for the time is interpreted as an unsigned value of (milli)seconds, and zero is defined as 1970-01-01T00:00:00.000 UTC. If you want to set the system time to any date/time before that, you would have to set that counter to a negative value – something that does not work for an unsigned value (as it is unsigned …).

There are several explanations around why the creators of UNIX chose that point in time for the 'Begin of the Epoch', and I have no clue which one is correct. But their decision for 1970 is the reason why you can't set your system to an earlier time.

  • I think it's from the C programming language, which was created in 1972. It would be reasonable for K&R to pick 1970 as the C epoch. It would then be reasonable for UNIX to inherit this
    – CSM
    Mar 8, 2020 at 11:32
  • is it signed or unsigned? Mar 8, 2020 at 12:29
  • 2
    the type used to store it time_t is signed, to aid calculation of time differences. But, IIRC, the meaning of a negative time (rather than timespan) is undefined.
    – CSM
    Mar 8, 2020 at 13:49
  • 1
    You always have to make a distinction between what the operating system (or the underlying firmware/hardware) stores physically(?) and how a programming language may interpret that value. In Java, System.currentTimeMillis() returns a long (that is signed …) and the constructor Date() takes also a negative value for a time/date before the beginning of 1970. But Java does not have any kind of functionality that would allow you to set the system time (beside calling date from a shell), therefore it does not matter that it uses a signed data type for displaying the system time.
    – tquadrat
    Mar 8, 2020 at 14:01
  • 4
    @CSM The C programming language was created to write Unix. The Unix project came first and coding started with B but K&R found that they needed more features so they implemented a better B and called it C. So it is inaccurate to say that Unix inherited this. It is more accurate to say Unix started this and incidentally Unix also started C
    – slebetman
    Mar 8, 2020 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.