Why is the Unix epoch January 1st 1970?

Question

In honor of this weekend being 1,600,000,000 (1.6 billion) seconds since the Unix epoch, I was wondering if anyone knows why January 1st 1970 was chosen?

According to Wikipedia,

The earliest versions of Unix time had a 32-bit integer incrementing at a rate of 60 Hz, which was the rate of the system clock on the hardware of the early Unix systems. The value 60 Hz still appears in some software interfaces as a result. The epoch also differed from the current value. The first edition Unix Programmer's Manual dated 3 November 1971 defines the Unix time as "the time since 00:00:00, 1 January 1971, measured in sixtieths of a second".^[16]

The User Manual also commented that "the chronologically-minded user will note that 2**32 sixtieths of a second is only about 2.5 years". Because of this limited range, the epoch was redefined more than once, before the rate was changed to 1 Hz and the epoch was set to its present value of 1 January 1970 00:00:00 UTC. This yielded a range of about 136 years, half of it before 1970 and half of it afterwards.

There's not really a mention of why it was chosen.

Honestly, it may be as simple as the logic below, but I'm curious if anyone has anything more definitive than a best guess.

1. They wanted to use midnight January 1st at GMT because it is the start of the year in a "neutral" timezone.
2. They used 1971 first because they could only express ~2.5 years of time when using 60 Hz intervals
3. They used 1970 when they updated to 1 Hz intervals to round it to a "nicer" number (1970 has an additional zero) and is close to the original epoch they used before.

One thing that sticks out is why not use the year 2000 instead of 1970? It is "nicer" than 1970 since it has more zeroes and is not so far in the future that the ~136 years of time that could be expressed before it is prohibitive (e.g., if you chose 2100 you could only express as far back as ~1964). (To be clear, I am not asking why not use 2000 since that makes the question more subjective, I am just pointing out that 1970 is not some immediately obvious special number.)

For an example of a timekeeping format that uses a more "meaningful" epoch there are (Time-based) UUIDs. They use midnight October 15th 1582 as the epoch because it was when the Gregorian calendar began being used.

Answer 1

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.

From Wired - Unix Tick Tocks to a Billion,

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.

Dennis Ritche also mentions the following, in his own retrospective of the Unix Manual, first Edition:

The first edition of the Unix Programmer's Manual, dated November 3, 1971, is available here in image, Postscript, and PDF format. Return with us to the golden days of yesteryear!

...

When I look over this manual, I'm amazed by a lot of things: first, by what has survived so long (the semantics of important system calls, and the important early commands) and also by what wasn't there. Neither pipes nor grep are in it, for example. Even B was not central (the manual apologizes that the B compiler is callable only by a shell script); C was still to come.

We even anticipated the millenium bug: time was measured in sixtieths of a second since 1 Jan. 1971 as a 32 bit quantity. The BUGS section for time(II) remarks, "The cronological-minded reader will note that 2**32 sixtieths of a second is only about 2.5 years." Later, this was patched more than once by declaring a new epoch, then again in 1973 by making the units full seconds dating from the 1970 New Year--this is the "classical" Unix epoch. Of course, it only pushed the issue off to 2038. Yet, the cal program even in 1971 knew about the hanky-panky in 1752!.

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.

Warner

Tricky as it was, that was exactly what Ritchie and Thompson did several times, as Warren Toomey recorded Ritchie saying, in The Restoration of Early UNIX Artifacts:

In consequence, during 1969–73, the epoch was changed several times, usually by back-dating existing files on disk and tape and changing the origin.

Poul-Henning Kamp recorded in an email, [LEAPSECS] presentations from AAS Future of Time sessions, that recompiles to change the origin were happening weekly at one point:

...

I have this directly from multiple persons who were involved back then, including Dennis Ritchie who gave me the full sordid details about the early UNIX' requirement of weekly recompiles to update the epoch of the timekeeping.

...

Notable dates

• V1 released 1972
  • or November 3, 1971 according to the date of the first edition of the manual
• V2 released June 1972
• V3 released February 1973
• V4 released November 1973
• V5 released June 1974
• V6 released May 1975
• V7 released January 1979
• V8 released 1985
• ...

Answer 2

Many of such decisions are arbitrary and only guided by major considerations. An OS designer, especially back then, did not sit down for days to muse about the best way, it's all about usability for the given task.

The story might have worked like this:

• We need a timestamp.
• Lets take the 60 Hz source.
• That way 32 Bit is fine to hold a whole year.
• Cool.
• Let's start at 1/1/1971, so we get a clean number.
• Handy when going thru dumps.
• Oops, we might to live longer than 2 years.
• Lets take seconds instead, that 60-fold the range, that's more than anyone will ever need (*1)
• Cool, done, lets move on.

Serious, later on people often add more thought than originally has been used.

Or in a more serious way:

Points in no particular order to think about

• Time zones do not matter. There is no inherent advantage for selecting any specific time zone, as 'moving' a date/time value into any other time zone will always require the same calculation, only the constants used change. Using UTC does avoid any disscusion about 'why' as it's the same 'zero point' used for all mapping as well.

• Starting from 1st of January is quite handy as it allows calculating the year of a given date/time value by simply subtracting a constant value for a years length (if not using a table, adjustment by leap years will be needed). To go from there to a date is again done by subtracting month values (or looking them up in a table), corrected by a leap day if after Feb 28th and dividable by four. So again straight forward.

• Using the year 2000 as base would not bring any advantage for calculation, but so disadvantages for usage due numbers being negative for decades to come:

  • All handling, even the most primitive, would have to be signed.
  • Simple binary sorting (like for logs) would be screwed when passing the 'zero point'
  • Calculations (like before) would be less simple
  • And (IMHO most important) timestamps in hex dumps aren't as easy to handle.

• And yes, 1970 is nice in human eyes. Easy to memorise. And after all, if the new clock can cover more than 100 years, it doesn't really matter to give up a year to 'beautify'. Such nice round days are a practice found in several systems. For example, BS2000 sets the machine clock (*1) to zero for January 1st 1950 - even though it wasn't developed until the late 1960s.

• Meaningful is always to be seen in a context. Unix time was designed to have a reliable time stamp for reporting, calculation of time passed (timers), marking file creation and update and alike. None of that needs to cover a time prior to system creation or many decades or even centuries. Its use for other purposes later on is a different story.

So long story short, 1/1/1970 is a very sensible date to use within scope and intended usage of Unix.

---

*1 - 640 Kib are more than ...

*2 - That clock is hardware driven with 64 bit width. Bit position 41 is incremented every microsecond, making it somewhat similar, as position 31 is incremented every 1.024 seconds. Any yes, all of the above calculations work as well quite fine - it's all about the correction values for hour and day :)

Answer 3

Memory and disk space were very short in the olden days. In my first (non-unix) job, most "dates" were expressed as WWY - where WW was the week number and Y was the last digit of the year.

So it was natural to use the biggest reasonable date that had a zero in the units year position as a base.

Time zones don't matter if you have built a few tonnes of immovable computer and you aren't bothered about email (the first "email" didn't happen until 1971).