Computing Limits · Exhibit

2038

The year the clocks run out of seconds

On Tuesday, 19 January 2038, at 03:14:07 in the morning (UTC), a quiet counter inside millions of computers will reach the biggest number it can hold.

One second later, if nobody has fixed it, it will not tick forward.

It will tick backwards - all the way to Friday, 13 December 1901.

Atmospheric ink etching of a vast dark server room filled with blinking machines and clocks, a large digital display frozen at 03:14:07, with a faint 1901 calendar drifting behind it

A clock that only counts

Your computer does not really know what day it is.

It knows only one thing: how many seconds have passed since a particular moment.

That moment is midnight at the start of 1 January 1970 (UTC). Programmers call it the epoch.

Every second since then, the count has gone up by one. When you check the time, your device takes that single, enormous number and quietly turns it into a date and a clock face.

At the moment you are reading this, the count is well past 1.7 billion.

It is called Unix time, after the operating system where it was born - and today it sits underneath phones, websites, databases, banks, routers and countless small machines.

Ink illustration of a mechanical odometer counting seconds since 1970, with a figure translating the number into a calendar and clock face

Ink illustration of people in party hats celebrating around a monitor showing 1234567890

Margin note

Birthdays for a number.

The counter has had its own milestones. It passed 1,000,000,000 seconds on 9 September 2001, and hit 1,234,567,890 on 13 February 2009 - a moment some programmers gathered to watch tick by.

Two programmers at Bell Labs

Unix was created at Bell Labs in New Jersey around 1969 by Ken Thompson and Dennis Ritchie, starting out on a little-used PDP-7 minicomputer.

The very first version of Unix time was even more cramped than today's. The 1971 manual describes it counting in sixtieths of a second from the start of 1971 - a counter that would have filled up in roughly two and a quarter years.

That clearly would not do. So the counting was changed to whole seconds, and the starting point was set back to a tidy, round date: 1 January 1970.

The count was kept in a box of 32 binary digits - plenty, it seemed, for a new operating system in a research lab. And it was stored as a signed number: one of those 32 digits records whether the number is plus or minus, which also lets the clock describe dates before 1970.

That left 31 digits for counting. Enough for about 68 years in each direction.

In the early 1970s, 68 years felt like forever. Nobody imagined that the same little counter would still be ticking inside the world's machines half a century later.

Ink illustration of two 1970s programmers beside a refrigerator-sized minicomputer, a paper printout with 1970 circled on the desk, and a shadowed 2038 calendar at the edge

Why exactly 2038?

Thirty-one binary digits can count up to exactly 2,147,483,647.

That is the largest number this kind of box can hold - a number with its own room in this museum.

Now read it as seconds.

2,147,483,647 seconds is about 68 years. Start counting at midnight on 1 January 1970, and you run out at precisely 03:14:07 UTC on 19 January 2038.

That is where 2038 comes from. Not from a prophecy or a planet alignment - just from a box with 31 counting digits and a clock that started in 1970.

Ink illustration of 32 light bulbs, one marked plus/minus, 31 glowing, with the number 2,147,483,647 above and a timeline arrow from 1970 to 2038 below

Ink illustration of a digital clock reading 03:14:07 softly echoing the pi symbol

Margin note

A slice of pi.

The last safe moment, 03:14:07, begins with 3.14 - the first digits of pi. It is pure coincidence, but it makes the date strangely easy to remember.

Ink illustration of a car odometer rolling from 99999 to 00000 beside a digital clock flipping from 2038 to 1901, with a clockwork figure flung backwards through calendar pages

One second too many

So what happens at 03:14:08?

Think of an old car's mileage counter showing 99999. Drive one more mile and it does not show 100000 - it rolls over to 00000.

The Unix counter rolls over too, but in a stranger way. Adding one to the biggest number flips that special "minus" digit on.

Suddenly the computer is not reading "a very large number of seconds after 1970". It is reading "a very large number of seconds before 1970".

The clock does not stop. It leaps backwards more than 136 years, to 20:45:52 UTC on Friday, 13 December 1901.

A payment could look as if it was made before it was requested. A security certificate could look expired, or not yet valid. A timer set to go off "in a few minutes" could decide it should have gone off 136 years ago.

The future is already here

You might think nothing can go wrong until 2038. But computers often work with dates in the future.

In May 2006, some web servers running a program called AOLserver suddenly started crashing.

The cause was a setting that told the software to wait up to one billion seconds before giving up on a request - a way of saying "wait forever".

One billion seconds is about 32 years. And on 13 May 2006, "now plus one billion seconds" crossed the 2038 line for the first time.

The calculation overflowed, the "deadline" landed in the past, and the servers fell over. The fix was simply to choose a smaller number.

It was the 2038 problem, arriving thirty-two years early.

Anything that plans ahead - a 30-year mortgage, a long-term certificate, a pension calculation - can bump into 2038 long before the clocks actually get there.

Ink illustration of a 2006 server room with one rack smoking, a thought bubble showing a stopwatch past a 2038 flag, and a tired engineer reading an error message

We have been here before

If this sounds familiar, it should.

In the late 1990s, the world worried about the Year 2000 problem - Y2K. For decades, many programs had stored years using only two digits, so "99" meant 1999. What would "00" mean? 2000, or 1900?

Governments and companies spent enormous sums - hundreds of billions of dollars worldwide, by common estimates - checking and repairing old software.

When midnight came on 1 January 2000, the lights stayed on. Planes kept flying. There were only scattered glitches.

Some people decided that Y2K had been a false alarm.

Most engineers who worked on it tell the story differently: it went smoothly because so many people spent years fixing it.

2038 is Y2K's quieter sequel. Different cause, same lesson: a number that seemed big enough when it was chosen turns out not to be.

Two-panel ink illustration: left panel shows New Year's Eve 1999 celebrations with office workers at computers, right panel shows a quiet 2038 scene with a single engineer at a laptop

Buying a bigger box

The fix is simple to describe: give the clock a bigger box.

Instead of 32 binary digits, use 64.

That one change is almost unimaginably powerful. A 64-bit counter of seconds will not run out for about 292 billion years - roughly twenty times the age of the universe so far.

Much of the world has already moved. Modern phones, laptops and servers mostly use 64-bit time. The Linux kernel, which runs a huge share of the world's servers and devices, made even its 32-bit versions ready to run past 2038 in 2020, with version 5.6.

The hard part is not the idea. It is finding every place the old, small box is still hiding.

Ink illustration comparing a tiny 32-bit box with a clock filling at 2038 to a vast 64-bit box whose timeline stretches past dying stars labelled about 292 billion years

Ink illustration cutaway of a city showing tiny chips inside cars, lifts, traffic lights, factory robots and smart meters, with engineers searching them with torches and magnifying glasses

Where the old clock hides

The most stubborn 2038 bugs will not be in your phone. They will be in the machines nobody thinks about.

Small computers are built into cars, factory machines, medical devices, lifts, traffic systems, electricity meters and industrial controllers. Many run for decades, and some are never updated at all.

Old files and databases can keep 32-bit dates inside them long after the software around them has been modernised.

Nobody can promise what will happen on 19 January 2038. It will probably look a lot like 1 January 2000: a quiet night, made quiet by a great deal of unglamorous work done in advance.

Why 2038 matters

2038 is not really about a year. It is about a promise every computer quietly makes: that the numbers it uses will be big enough.

Usually they are. Sometimes the promise lasts decades. But every box of digits, however large, has an edge.

The programmers who chose 32 bits in the early 1970s were not careless. They were solving the problem in front of them. They simply could not know how far their choice would travel.

That is the real story of 2038: small decisions, made for today, have a way of outliving the people who made them.

Ink illustration of a road made of binary digits stretching from a 1970 signpost toward a cliff at 2038, where engineers build a wide bridge labelled 64

2038 in a nutshell

Here is why 2038 matters:

Many computers track time as the number of seconds since 1 January 1970 (UTC).
In the classic design, that count is stored in a 32-bit box with one digit reserved for "minus".
The biggest number it can hold is 2,147,483,647 - about 68 years of seconds.
That runs out at 03:14:07 UTC on 19 January 2038.
One second later, the count wraps round to 13 December 1901.
It has already caused real bugs, such as the AOLserver crashes of May 2006.
The fix is 64-bit time, good for about 292 billion years - and most modern systems already use it.
The risk lingers in old, embedded and forgotten machines.