Why does Unix time start at 1970-01-01? Why not 1971-01-01 or any other date?
I wouldn't have known the answer except google was there for me:
From Here (needs free subscription):
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.
Unix isn't born in 1970.
The Unix epoch is midnight on January 1, 1970. It's important to remember that this isn't Unix's "birthday" -- rough versions of the operating system were around in the 1960s. Instead, the date was programmed into the system sometime in the early '70s only because it was convenient to do so, according to Dennis Ritchie, one of the engineers who worked on Unix at Bell Labs at its inception.
I like the question :-)
Let me attempt to answer it (ofcourse source: internet)
Unix Time is represented by a 32 bit whole number (an integer) that can be positive or negative (signed). Unix was originally developed in the 60s and 70s so the "start" of Unix Time was set to January 1st 1970 at midnight GMT (Greenwich Mean Time) - this date/time was assigned the Unix Time value of 0. This is what is know as the Unix Epoch.
A 32 bit signed integer can represent whole numbers between -2147483648 and 2147483647. Since Unix Time starts at 0, negative Unix Time values go back in time from the Epoch and positive numbers go forward in time. This means that Unix Time spans from Unix Time value of -2147483648 or 20:45:52 GMT on December 13th 1901 to Unix Time value of 2147483647 or 3:14:07 GMT on January 19 in 2038. These dates represent the beginning, the pre-history and the end of Unix Time.
The end of Unix Time will occur on January 19, 2038 03:14:07 GMT. On January 19, 2038 03:14:08 GMT all computers that still use 32 bit Unix Time will overflow. This is known as the "Year 2038 problem". Some believe this will be a more significant problem than the "Year 2000 problem". The fix for the Year 2038 problem is to store Unix Time in a 64 bit integer. This is already underway in most 64 bit Operating Systems but many systems may not be updated by 2038.
This comment from JdeBP piqued my interest:
Psst! Dennis Ritchie is on the record about this, to Poul-Henning Kamp, Warren Toomey, and Wired. Warner Losh has also reported on this... Find out what dmr actually told people about this.
Therefore, here is Dennis Ritchie's comment about this, as well as a brief expanation of the overflow that he mentions.
The Unix epoch is midnight on January 1, 1970. It's important to remember that this isn't Unix's "birthday" -- rough versions of the operating system were around in the 1960s. Instead, the date was programmed into the system sometime in the early 70s only because it was convenient to do so, according to Dennis Ritchie, one [of] the engineers who worked on Unix at Bell Labs at its inception.
"At the time we didn't have tapes and we had a couple of file-systems running and we kept changing the origin of time," he said. "So finally we said, 'Let's pick one thing that's not going to overflow for a while.' 1970 seemed to be as good as any."
There are approximately 32 millions seconds in a year, which means that it takes about 31 years for a billion seconds to pass. Apparently, earlier this year, some mathematically inclined provocateurs discovered that the year 2001 marked 31 years since 1970, and some of them assumed that this might represent an "overflow" -- the date buffer filling with digits, causing the computer to go wacky.
In addition, and with a bit more historical detail, Warner Losh stated in an email, Re: [TUHS] The 2038 bug..., on 4 Jan 2021:
My understanding is that it's been 1st Jan 1970 since at least Ed5, if not Ed6.
It's been that way since the 4th edition.
In the 3rd edition it was the number of 60Hz ticks since 1972, along with this note: "This guarantees a crisis every 2.26 years."
Rebasing the epoch would be... tricky... lots of math is done assuming an origin of 1970, and not all of it is obvious to even concerted analysis.
Less ugly would be to declare time_t to be unsigned instead of signed... It would break less code... Making time_t 64 bits also breaks code, even if you declare you don't care about binary compat since many older apps know time_t is 32-bits.