Why January 1, 1970 — The Story Behind the Unix Epoch

Every Unix system on Earth measures time as seconds since exactly midnight UTC on January 1, 1970. Why that date specifically? Why not the year of the Big Bang, or the first day of the first computer, or some other meaningful anchor?

The honest answer: it was an arbitrary choice made by Bell Labs engineers in 1971, picked for convenience, that has stuck for fifty-five years because everything is built on it now. There is more to it than that, but not as much as you might think.

How Bell Labs Picked January 1, 1970

Unix was developed at Bell Labs starting in 1969. The first edition of the Unix Programmer's Manual, published in November 1971, defined system time as "the time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second."

That is right — the original Unix epoch was 1971, not 1970. And it was 60ths of a second (one tick per HZ on the 60 Hz US power grid), not seconds. This had a real problem: a 32-bit unsigned counter at 60 ticks per second runs out in about 2.26 years. By late 1973 the system would have stopped working.

So Unix was redesigned to count seconds instead of 60ths, and the epoch was rewound to January 1, 1970 — partly because it was a clean date, partly because it pushed the rollover further into the future, and partly because Ken Thompson and Dennis Ritchie just liked round numbers.

Documented in the second edition of the Unix manual (June 1972). It has not changed since.

Why Not Pick a Date Before 1970

Several historically meaningful dates were on the table. None of them won.

• January 1, 1900 — used by NTP (Network Time Protocol) and several real-time systems. Pre-dated the Unix epoch by 70 years.
• January 1, 1601 — used by Microsoft Windows internally (FILETIME). Picked because 1601 was the start of a 400-year Gregorian leap cycle.
• October 15, 1582 — the start of the Gregorian calendar itself. Used by some genealogy software.
• January 1, 1, A.D. — used by .NET DateTime internally. The "year 1" of the proleptic Gregorian calendar.

Bell Labs picked 1970 because Unix was a contemporary operating system used to track contemporary events. There was no business need to record dates from the 1800s, and using a recent epoch made the integer values smaller.

The drawback is that Unix time cannot natively represent dates before 1970 without using negative numbers (which work but make a lot of code error-prone). For working with historical dates, Unix time is the wrong tool — use a calendar library that supports the BCE / pre-Gregorian range.

Sell Custom Apparel — We Handle Printing & Free Shipping

Why UTC Specifically

Unix time is always in UTC. The rationale is the same as picking any global reference point: avoiding ambiguity.

If Unix time were measured in local time, two events that happened at the same instant on different sides of the world would have different timestamps. Subtracting them would give the wrong duration. Comparing them would give the wrong order. Storing them in a database would create rows that look out of sequence.

UTC sidesteps all of that. Every Unix timestamp anywhere in the world for the same moment is the exact same number. The complications of timezones and daylight savings only enter when you display the value to a human — which is exactly the right place for that complexity to live.

This is why the rule "store in UTC, display in local" is the foundation of every good timestamp design. It works because Unix time gave us a clean global reference to build on.

What This Means Today

The 1970 epoch is now embedded in roughly everything. C standard library, POSIX, Linux, macOS, Windows (which has its own epoch but exposes Unix time via APIs), JavaScript, Java, Python, Go, Rust, every major database, every major web framework, every cloud service, every file system that stores modification times.

That ubiquity is why nobody has seriously proposed changing the epoch even though we know about its problems (the 2038 rollover for 32-bit systems, the inability to represent pre-1970 dates without negative numbers). Changing it would break backward compatibility with everything that has been written since 1972. The fix for 2038 is to use 64-bit storage, not to move the epoch.

So when you see a Unix timestamp like 1711000000, you are seeing a number whose meaning was fixed by two engineers at Bell Labs more than 50 years ago. The decision was practical, the consequences were enormous, and we live with it every day.

To convert any Unix timestamp to a human-readable date, paste it into the free Unix timestamp converter. To dive deeper into how Unix time works in code, see the complete Unix timestamp reference.

Frequently Asked Questions

Why is Unix epoch January 1, 1970?

It was a practical choice made at Bell Labs in 1971-1972 when redesigning Unix time to count seconds instead of 60ths of a second. They picked 1970 because it was a clean recent date that made the integer values manageable and pushed the 32-bit rollover into the distant future. There is no deeper meaning to the year.

Was the original Unix epoch 1970 or 1971?

The first edition of Unix used January 1, 1971 with 60ths of a second. That overflowed too quickly (about 2.26 years for a 32-bit counter), so the second edition switched to seconds and rewound the epoch to January 1, 1970. The 1970 version has been the standard ever since.

Can Unix time represent dates before 1970?

Yes, by using negative numbers — the timestamp -1 is December 31, 1969 at 23:59:59 UTC. But many programs and libraries do not handle negative timestamps correctly, so it is risky in practice. For historical dates, use a proper calendar library instead of Unix time.

Why is Unix time in UTC?

A global reference point avoids ambiguity. If timestamps used local time, the same instant in different time zones would have different numbers, breaking comparisons and ordering. UTC means every Unix timestamp anywhere in the world for the same moment is the same number.

Did any operating system ever use a different epoch?

Yes. Windows uses January 1, 1601 internally (FILETIME). Classic Mac OS used January 1, 1904. NTP uses January 1, 1900. .NET DateTime uses January 1, year 1. Each was picked for its own reasons. Modern systems all expose Unix time alongside their internal epoch for compatibility.

Will the Unix epoch ever change?

No serious proposal exists. Changing it would break every program written since 1972, every file format that stores timestamps, every database, every API. The known problems with the 1970 epoch (the 2038 rollover) are being fixed by moving from 32-bit to 64-bit storage instead of moving the epoch.