29

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?

Braiam
  • 67,791
  • 32
  • 179
  • 269
Aven Desta
  • 512
  • 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 06 '20 at 22:02
  • This is a massive interoperability problem for Amiga users, whose epoch is January 1st, 1978. – Simon Richter Mar 07 '20 at 08: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? – Thomas Weller Mar 08 '20 at 16:01
  • 1
    Can I ask why you want the date set prior to 1970? Just curious. – B-K Mar 09 '20 at 01: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 09 '20 at 12:37
  • @IMSoP, my first attempt was to change the date/time at setting. Go to setting, then Details, then disable automatic date/time, finally try to change the date to less than 1970. The same happened when I use other means. – Aven Desta Mar 09 '20 at 14:32
  • @ThomasWeller, kinda like that – Aven Desta Mar 09 '20 at 14:35

3 Answers3

29

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}.

K7AAY
  • 17,202
  • 14
    It's signed 32-bit though, so it should (and in most cases does) work back to late 1901. – hobbs Mar 07 '20 at 04:49
  • 7
    Using 1970 allows it to reach 2038 with a 32-bit signed int. – ikegami Mar 07 '20 at 05:20
  • @hobbs POSIX doesn't specify whether time_t is signed or unsigned; it just has to be an integer type. – chepner Mar 08 '20 at 23:17
  • 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. – Sandy Chapman Mar 09 '20 at 01:00
  • 1
    @Sandy Chapman TY for pointing to an issue which needed documenting. – K7AAY Mar 09 '20 at 01:45
  • @chepner it doesn't, but I haven't encountered a system that had it unsigned, and Ubuntu sure isn't one :) – hobbs Mar 09 '20 at 02:39
  • 1
    10 Adar 5780 is the date you wrote this answer, not 0AD. That last sentence is really ambiguous. – J... Mar 09 '20 at 13:57
14

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.

Community
  • 1
schrodingerscatcuriosity
  • 4,246
  • 14
  • 28
  • 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 09 '20 at 12:43
4

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.

tquadrat
  • 141
  • 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 08 '20 at 11:32
  • is it signed or unsigned? – Thorbjørn Ravn Andersen Mar 08 '20 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 08 '20 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 08 '20 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 08 '20 at 15:28
  • @ThorbjørnRavnAndersen Yes. :) POSIX only requires time_t to be an integer type. It doesn't require it to be signed or unsigned specifically. – chepner Mar 08 '20 at 23:18
  • There would seem to be little reason not to use a signed 64-bit type, though. I can't imagine needing to represent dates prior to 584,000,000,000 BCE, and I'll go out on a limb and say that there will be no Y584B problem to deal with. – chepner Mar 08 '20 at 23:22
  • @CSM That seems like it would be a better basis for an answer than what we currently have on this page, because there doesn't seem to be any evidence for systems actually using an unsigned integer. POSIX does indeed state that "the relationship is undefined" for negative values so maybe the system tools avoid accepting those values? – IMSoP Mar 09 '20 at 13:01
  • @chepner, back in the early 1970s memory was expensive. Using 4 bytes for a date would have been seen as an extravagance. They also didn't anticipate that UNIX would be around for the next 50 years. BTW, time_t is now a 64-bit value – CSM Mar 14 '20 at 13:30
  • @CSM I should have clarified that I meant today, not when an epoch-based time type was introduced. POSIX still doesn't specify how big time_t must be, but I suspect that where feasible, 64 bits is chosen over 32 bits. – chepner Mar 14 '20 at 14:16