Counting Seconds Since 1970: The Strange History of Unix Time

Somewhere in the computer you are reading this on, a number is ticking upward. Right now it's a little under two billion, and it goes up by exactly one every second. That number is how your phone, your laptop, the server that sent you this page, and nearly every database on Earth agree on what time it is.

It is Unix time: the count of seconds since midnight UTC on 1 January 1970. It shows up in log files, API responses, JWT tokens and git commits, and most of the time nobody looks at it. The story behind it includes a clock that would have run out in two years, a date picked mostly because it was a round number, a leap second that knocked big websites offline, and a deadline in 2038 that engineers are still working to beat.

A clock built to last two years

Unix was born at Bell Labs in 1969 on a secondhand PDP-7, and its first clock was not the one we know. The earliest Unix manuals defined system time as a 32-bit counter ticking in sixtieths of a second, the rate of the machine's line-frequency clock, measured from the start of 1971.

That design had an obvious flaw. A 32-bit counter ticking 60 times a second overflows in about 2.3 years. Early Unix handled this by resetting the epoch whenever it got close, and 1971 and 1972 were both used as starting points during those first years.

By late 1973 the engineers had changed both halves of the design. The counter would tick once per second instead of 60 times, which stretched its life from about two years to about 68 in each direction. The starting point moved back to 00:00:00 GMT, 1 January 1970. Nothing notable happened on that date. The people involved later said they picked it because it was a round number close to the present, which suited a system that was expected to be rewritten long before the counter mattered.

It wasn't rewritten. A choice made for a research operating system was later written into POSIX, copied by C libraries, and inherited by Linux, macOS, Android, iOS, JavaScript, Python, Java and almost every database in use. The arbitrary date became the default reference point for nearly all software.

One number, no time zones

Unix time has lasted this long because it is so simple.

1790000000  →  2026-09-21 14:13:20 UTC

It has no time zones, no daylight saving, no calendar months of unequal length and no locale formats. The same second has the same value in Tokyo and in Toronto. Comparing two moments is a subtraction. Sorting events is sorting integers. Converting to a human-readable date is left to the last step, where the reader's time zone gets applied.

The format is also easy to read at a glance. A 10-digit number starting with 1 is almost certainly a Unix timestamp in seconds. If it has 13 digits, it's milliseconds, which is JavaScript's Date.now(). At 16 digits it's microseconds, and at 19 it's nanoseconds. Engineers learn to recognise all four on sight.

Parties for round numbers

Because the counter only goes up, it sometimes lands on a memorable number, and programmers have celebrated these moments.

On 9 September 2001 at 01:46:40 UTC, Unix time reached 1,000,000,000. The "billennium" was marked with gatherings in Copenhagen and elsewhere, and with a fair amount of nervous testing. Some software that stored timestamps as nine-character strings, or sorted them as text, broke when a tenth digit appeared.

On Friday 13 February 2009 at 23:31:30 UTC, the counter read 1234567890, and "1234567890 day" parties were held in cities around the world. The next milestone, 2,000,000,000, arrives on 18 May 2033.

The leap second problem

Unix time depends on a simplification: every day is treated as exactly 86,400 seconds long.

The Earth doesn't cooperate. Its rotation is slowly and irregularly slowing down, so since 1972 timekeepers have inserted 27 leap seconds into UTC. Each one produces a minute with 61 seconds, where the clock reads 23:59:60 before midnight. Unix time has no value for that second. When a leap second arrives, the counter repeats a second or stalls, and for one second time is ambiguous.

For years this mostly didn't matter. Then, on 30 June 2012, a leap second triggered a bug in the Linux kernel's timekeeping code, and servers around the world got stuck using 100% CPU. Reddit, Mozilla, LinkedIn and Yelp all had problems. The Amadeus reservation system also went down, and Qantas staff had to check passengers in by hand at Australian airports.

On 1 January 2017 another leap second hit Cloudflare. Its DNS software computed a time difference that came out negative because the clock had repeated a second. Code that assumed time only moves forward started failing, and some customers' DNS lookups broke for several hours.

The industry responded in two ways. Google and others began smearing the leap second, speeding up or slowing down their clocks by tiny amounts over 24 hours so that no minute ever has 61 seconds. Then in November 2022 the General Conference on Weights and Measures went further and voted to abolish leap seconds by 2035. Unix time's assumption that a day is always 86,400 seconds was, in effect, adopted by the world's timekeeping authorities.

Every system picks its own epoch

1970 is the most common epoch, but it isn't the only one. Every timekeeping system needs a day zero, and the choices can be surprising.

Each epoch has its own rollover risk. The one that affects the most software is 2038.

03:14:07, 19 January 2038

Unix time was traditionally stored in a C type called time_t, which for decades was a signed 32-bit integer. Its largest value is 2³¹ − 1, or 2,147,483,647.

That many seconds after the epoch is 03:14:07 UTC on Tuesday, 19 January 2038. One second later, a 32-bit time_t overflows and wraps around to its most negative value. Software that still uses one will think the date is 20:45:52 UTC on Friday, 13 December 1901.

This is the Year 2038 problem, sometimes called Y2K38. It is a harder problem than Y2K. That bug came from how dates were written, and it could often be fixed at the application level. This one is about how time is stored, in the fixed-width binary layouts of file formats, network protocols, database columns and the firmware of embedded devices that can run for decades without an update.

It has also caused failures already. Any software that calculates dates far in the future runs into 2038 early. In May 2006, the AOLserver web server started failing because it set "never expire" timeouts to one billion seconds in the future, and from 13 May 2006 onward that date was past the 32-bit limit. Loan and insurance software that projects 30 years ahead hit the same problem in 2008.

The fix: 292 billion years

The fix is simple to describe and slow to roll out: use 64 bits. A signed 64-bit count of seconds lasts about 292 billion years, roughly twenty times the current age of the universe.

Most of the work has been done. 64-bit operating systems have used a 64-bit time_t for a long time. Linux 5.6, released in 2020, made even 32-bit systems 2038-safe at the kernel level, and glibc followed with 64-bit time support for 32-bit programs. Modern databases, languages and file systems mostly handle dates past 2038.

What remains is the long tail. That includes old binary file formats, database columns declared as 32-bit integers, and embedded controllers in cars, routers, industrial equipment and medical devices that were installed years ago and never updated. Some of the hardware that will be running in 2038 is already in use now.

The designs that came later mostly left more room. JavaScript counts milliseconds in a 64-bit float and goes to the year 275,760. The UUID version 7 format described in our history of the UUID puts a 48-bit Unix millisecond timestamp at the front of each ID, which lasts until the year 10,889.

A counter that keeps going

When Bell Labs engineers moved their clock back to 1970 and switched it to seconds, they were fixing a short-term problem on a research machine. They didn't expect the number to outlast most of the hardware they were using, or to end up inside every phone, bank transfer and log line.

It did, though, and the counter is still running. Every login token that expires on time, every file sorted by date and every event ordered correctly across two continents depends on the same count of seconds that started in 1970.