The Year 2038 Problem: How a Single Number Could Break Computers (and Why Time Starts in 1970)

At exactly 03:14:08 in the morning, Coordinated Universal Time, on Tuesday the 19th of January 2038, a number that quietly runs a large slice of the world's computers will run out of room. For a great many systems nothing will happen. For an unlucky few — older servers, embedded chips humming away inside machinery nobody has thought about in twenty years — time will appear to leap backwards to December 1901. Engineers have a nickname for this moment, half-joking and half-nervous: the Epochalypse.

To understand why a single second in 2038 matters, you have to understand the strange, beautiful, slightly absurd way computers keep time in the first place. And the best way to feel it is to watch the number itself tick.

Time as one big number

Humans tell time with an elaborate scaffolding of years, months, leap days, time zones and daylight saving. Computers find all of that exhausting. So underneath the friendly clock on your screen, most systems track time as a single integer: the number of seconds that have passed since one fixed instant.

That instant is the Unix epoch: midnight UTC on the 1st of January, 1970. Everything since is just counting up. Right now, as you read this, that counter sits somewhere north of 1.7 billion. You can watch it advance one second at a time on a Unix timestamp converter — a plain, ever-growing number that is, remarkably, how your phone, your bank, and most of the internet actually understand "now."

The elegance is the point. A timestamp like 1700000000 is unambiguous. It means the same instant in Tokyo, London and São Paulo; only the human translation differs. There are no time zones to fight over, no calendars to reconcile, no leap-year arithmetic to botch. Want to know if one event happened before another? Compare two integers. Want to know how long something took? Subtract. An entire universe of date complexity collapses into ordinary arithmetic.

Why 1970, of all years?

People assume the epoch must mark something momentous. It doesn't. It marks a coffee-break decision.

Unix was taking shape at Bell Labs at the tail end of the 1960s and the start of the 1970s, built by a small group including Ken Thompson and Dennis Ritchie. They needed a zero point for their clock. The very first versions actually counted time in sixtieths of a second — tied to the 60-hertz hum of American mains electricity — which meant the counter ballooned so fast it would overflow in a couple of years. That was clearly impractical, so they switched to counting whole seconds and picked a nice round, recent date to start from: the beginning of 1970.

There was no grand reasoning, no astronomical event, no historic anniversary. It was simply close at hand and tidy. And because Unix went on to underpin Linux, macOS, Android and the servers that run almost everything, that arbitrary January morning in 1970 became the silent origin of time for the digital world. Half a century of software now agrees that history began on a Thursday.

The ceiling nobody noticed until later

Here's where the trouble hides. A number stored in a computer doesn't have infinite room; it lives in a box of a fixed size. For decades, the standard box for a Unix timestamp was a signed 32-bit integer — a container that can hold values up to 2,147,483,647.

Count seconds from 1970, and you hit that maximum at 03:14:07 UTC on the 19th of January, 2038. One second later, the box overflows. Because the integer is signed — it reserves one bit to mark positive or negative — rolling past the top doesn't wrap to zero; it flips to the most negative value possible. The timestamp suddenly reads as a huge negative number, which translates to a date in December 1901. To an affected system, time has just fallen off a cliff and landed 137 years in the past.

What happens next depends entirely on the software. A logging system might scramble its records. A device that checks whether a security certificate is still valid might decide every certificate expired a century ago — or won't be valid for another century. Anything that calculates a duration by subtracting two timestamps could produce wild, negative nonsense. It is, in spirit, the same flaw as the famous Year 2000 bug: a value that was "obviously big enough" right up until it wasn't.

We have actually seen this before

The 2038 problem isn't theoretical doom; the future has already leaked into the present several times, whenever a piece of software tried to represent a date past that 2038 ceiling.

Systems that calculate far-off dates — a 30-year mortgage, a long bond, a "remind me in 25 years" feature — have repeatedly tripped the bug early by reaching across the boundary. There are well-documented cases of booking and finance systems choking the moment they tried to handle a date in 2038 or beyond, throwing errors or silently corrupting the value, sometimes decades ahead of the actual deadline. Each one is a small preview of the main event, and a useful warning: the bug bites not in 2038, but the first time any system does arithmetic that crosses the line.

If you're curious, you can poke at the boundary yourself. Feed the number 2147483647 into a timestamp converter and you'll land precisely on that January 2038 morning; add one and watch a well-built converter still cope, because it isn't trapped in a 32-bit box.

The fix is real — but unevenly applied

The good news is that the solution is known, simple, and already widespread: use a bigger box. Move the timestamp from 32 bits to 64 bits, and the ceiling leaps from 2038 to roughly 292 billion years from now — comfortably past the expected lifespan of the Sun, the Earth, and any computer that might care.

Modern 64-bit operating systems, current versions of Linux, today's phones and virtually all new software already store time this way. For most people reading this, the Epochalypse is a non-event. The danger lives elsewhere: in the long tail of devices that are easy to forget and hard to update. Industrial controllers, medical equipment, car components, power-grid hardware, networking gear and countless embedded chips were built years ago with 32-bit time and a working life measured in decades. Many will still be running in 2038, buried inside machines no one plans to patch. Tracking them all down is the slow, unglamorous work quietly underway across the industry right now.

The other quirk: the seconds that don't exist

While we're prying open the clock, there's a second oddity worth knowing, because it surprises even experienced programmers. Unix time pretends every day is exactly 86,400 seconds long. Reality disagrees.

The Earth's rotation is gradually, irregularly slowing, so since 1972 the world's timekeepers have occasionally inserted a leap second — an extra tick — to keep our precise atomic clocks aligned with the actual turning of the planet. More than two dozen have been added over the years. But Unix time flatly ignores them. To keep that clean "seconds since 1970" arithmetic from breaking, a Unix clock simply repeats or stretches a second when a leap second occurs, so the count stays tidy even though the real world briefly disagrees.

This sounds harmless until a leap second actually arrives, at which point systems that suddenly see a repeated or impossible timestamp can misbehave — a few notable internet outages have been traced to exactly this. The fix the tech giants landed on is charming: rather than insert a jarring extra second, they "smear" it, slowing their clocks by a sliver across a whole day so the leap second dissolves invisibly. And in a sign of how much trouble these stray seconds cause, the world's metrologists voted in 2022 to abolish the leap second altogether by 2035. Even our corrections to time, it turns out, need corrections.

A number worth respecting

It's easy to look at a Unix timestamp — a bland string of ten digits — and see nothing but plumbing. But that number carries a surprising amount of history and fragility. It begins at an almost accidental moment in 1970, chosen over a Bell Labs coffee break. It powers the entire modern internet by turning the chaos of human calendars into simple arithmetic. It harbours a built-in expiry date in 2038 that engineers are still racing to defuse in the world's forgotten machines. And it quietly papers over the fact that our own planet refuses to keep perfect time.

The next time you need to translate one of these numbers into a date a human can read — checking when a file was created, when a token expires, or just what 1700000000 actually means — it's worth remembering what you're really looking at. You can convert any timestamp, in seconds or milliseconds, and watch the live count climb second by second with a Unix timestamp converter. It's a tiny window onto one of the most quietly important numbers ever invented — and a reminder that even time, in a computer, is just something somebody decided to start counting one ordinary winter's day.