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.

  • 4
    This is already on Stack Exchange long since at unix.stackexchange.com/q/26205/5132 and stackoverflow.com/q/1090869/340790 of course. See also stackoverflow.com/q/11573024/340790 .
    – JdeBP
    Sep 11, 2020 at 22:16
  • 1
    Setting the base to 2000 in 1970 is problematic, at least from a C runtime library point of view, because a time_t value of -1 is "not a time". So there'd be a chronological singularity looming ahead for that choice. And I suspect that much code treats negative time as an error. My question would be, though, why the time was considered to be a signed value. Maybe it just fell out when everything in C was an int unless specifically declared otherwise. Sep 11, 2020 at 23:14
  • 3
    1970 is a particularly awkward year to choose for those of us in the UK, because the UK was on summer time (GMT+1) continuously from summer 1968 to summer 1971.  So the Unix epoch was at 01:00 in local UK time, which can be surprising…
    – gidds
    Dec 19, 2020 at 12:54
  • 2
    I was born 13 years before that and let me tell you, there wasn't diddly any earlier! Ooops, my bad - yes, there was - yes, there was. Jun 25, 2021 at 22:08
  • 3
    The UK double summertime issue still bites people to this day, especially those doing epochs and databases incorrectly or with dodgy localisation settings. Of course, though the decision was the UKs, the bug may arise anywhere in the world that GMT is used carelessly in this way. I've encountered it three times in my career and my colleagues call it Harold Wilson's Bug. Jun 26, 2021 at 20:58

2 Answers 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 :)

  • 1
    most systems use an epoch that's older than the age of that system. For example Windows uses 1/1/1601, Lotus uses 0/1/1900 en.wikipedia.org/wiki/Epoch_(computing)
    – phuclv
    Sep 12, 2020 at 12:22
  • 1
    1970 has the supreme advantage of being after most[] Julian->Gregorian conversions, meaning that you can easily convert all positive "seconds after epoch" to a date-time using the same computation (almost) no matter the locale you're doing the conversion in. [] Looks like Saudi-Arabia converted from Islamic to Gregorian calendar in 2016.
    – Vatine
    Sep 12, 2020 at 15:55
  • 1
    Using the year 2000 as base would not bring any advantage for calculation - Leap years in the Gregorian calendar are on a 400-year cycle, so doing so makes leap year/day calculations easier. In fact, the java date/time api (and a few others, probably) internally re-zeros to the year 2000 (or sometimes 0) to make its calculations easier/simpler. Sep 13, 2020 at 5:12
  • @Clockwork-Muse Not really, as 2000 was a leap year, as it's dividable by 400. therefore any year between 1601 and 2399 offers the same advantage.
    – Raffzahn
    Sep 13, 2020 at 15:14
  • "...that's more than anyone will ever need..." - which immediately precedes, "If this is still running when they run out", which is itself immediately followed by raucous laughter. Jun 25, 2021 at 22:12

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

  • 1
    The number of characters in the written form of a date-time does not seem to be related to a date-time that is held as a simple integer count (seconds since 1970). Sep 11, 2020 at 22:31
  • 2
    Psst! Dennis Ritchie is on the record about this, to Poul-Henning Kamp, Warren Toomey, and Wired. Warner Losh has also reported on this. And Raffzahn has it wrong. You want to write a better answer? Find out what dmr actually told people about this.
    – JdeBP
    Sep 12, 2020 at 7:44
  • 7
    Well, that's a bit of a tease, isn't it? Do you have a link for us? Sep 13, 2020 at 19:40
  • 2
    @JdeBP, since you're better informed, it seems sensible that you should write the correct answer, with references. Jun 26, 2021 at 12:13

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.