The Year 2038 Problem: When Computers Discover Time Is Hard

For most of human history, keeping track of dates was relatively straightforward. The sun came up; the sun went down.

Somebody invented a calendar; somebody else, immediately, disagreed with it.

Civilization continued, unimpeded, mostly.

We lost eleven days when calendars with small yearly inaccuracies were switched with more accurate models.

Then, computers arrived and decided that time should be represented as an integer counting seconds since January 1, 1970.

And honestly, that seemed like a perfectly reasonable idea. For a time, it was good.

The Tiny Design Decision That Became Everyone’s Problem

Many operating systems and applications historically stored time as a signed 32-bit integer. Specifically, this represented the number of seconds since January 1, 1970. A signed 32-bit integer can hold values up to 2³¹-1.

or:

2,147,483,647 seconds

Which sounds like a lot.

Because it is.

Unfortunately, computers are very patient.

Eventually they count all the way to the end.

And when they do, things get weird.

The Day Time Runs Out

At precisely:

2038-01-19 03:14:07 UTC

a signed 32-bit Unix timestamp reaches its maximum value.

One second later:

2038-01-19 03:14:08 UTC

the value overflows.

Instead of moving forward in time, many affected systems wrap around into the distant past.

Because if there’s one thing computers enjoy, it’s confidently being wrong.

A system expecting 2038 might suddenly believe it is 1901.

Which is awkward.

Especially for financial systems.

And, security systems.

And, operating systems.

And, literally anything that cares what year it is.

That’s the counterintuitive part of the Year 2038 Problem. Unix time is traditionally stored as a signed 32-bit integer representing the number of seconds since:

1970-01-01 00:00:00 UTC

The largest positive signed 32-bit integer is:

2³¹-1=2,147,483,647

which corresponds to:

2038-01-19 03:14:07 UTC

At the next second, the value would ideally become 2,147,483,648,but a signed 32-bit integer can’t represent that value. Instead, the bit pattern wraps from:

01111111 11111111 11111111 11111111

to:

10000000 00000000 00000000 00000000

which is interpreted as −2,147,483,648 in two’s complement arithmetic.

Now, recall, Unix timestamps are measured relative to 1970.

So a timestamp of −2,147,483,648 means:

2,147,483,648 seconds BEFORE1970-01-01 00:00:00 UTC

That works out to:

1901-12-13 20:45:52 UTC

So the sequence looks like:

2038-01-19 03:14:062038-01-19 03:14:071901-12-13 20:45:521901-12-13 20:45:53...

Surely We Fixed This Already?

Mostly.

The industry response has generally been, perhaps we should use larger numbers.

A revolutionary concept. Sarcasm. Bygones. Moving on.

Modern operating systems increasingly use 64-bit timestamps.

This increases the available range from two billion seconds to 2⁶³-1 seconds for signed timestamps.

Which is substantially more. By “substantially more,” we can assume the heat death of the universe may become the more immediate concern. Ok, not really, but I’m going for dramatic effect.

The Real Problem

The challenge isn’t updating one operating system.

The challenge is updating everything.

And humanity has accumulated a truly impressive collection of things that keep track of time. It was at this point that I spent an hour looking around for information on pacemaker firmware / OSes, useful life, ability to do software / firmware updates, and similar information. There isn’t much out there. Security considerations around embedded devices inside the human body is a fascinating topic that I’ll have to explore at a later date.

Consider:

• Operating systems
• Embedded systems
• Routers
• Industrial control systems
• Medical equipment
• Security cameras
• Smart TVs
• Automobiles
• Airplanes
• Satellites
• That Linux server nobody has touched since 2007 because everyone is afraid to reboot it

Every one of these systems potentially contains code that assumes a 32-bit timestamp.

Some assumptions are obvious; others are buried inside forgotten source code written by a developer who now lives on a sailboat and cannot be reached (or is dead).

The Migration Effort

Updating a timestamp representation sounds easy.

Replace:

int32_t timestamp;

with:

int64_t timestamp;

Problem solved.

Unfortunately, software engineering has never allowed anything to be that simple.

Changing timestamp sizes can affect:

• Database schemas
• APIs
• Network protocols
• File formats
• Serialization logic
• Memory layouts
• Binary compatibility
• Third-party integrations

Some systems have timestamps embedded in places so obscure that archaeologists may one day mistake them for religious artifacts.

The actual migration effort involves years of:

• Auditing
• Refactoring
• Testing
• More testing
• Discovering undocumented dependencies
• Additional testing

And finally:

• Deploying patches

followed by:

• Discovering the one thing nobody tested

Otherwise, known as software development.

What If We Counted All The Way To ²⁶⁴ Seconds?

Since we’re already discussing absurdly large numbers, let’s ask an important question:

What happens when we reach 2⁶⁴ seconds after January 1st, 1970? The answer is surprisingly specific.

The date would be:

November 9, 584,554,051,22307:00:16 UTC

And because, somebody was eventually going to ask, it falls on a Thursday.

That’s right.

More than 584 billion years into the future. Still a Thursday. It’s better than it happening on a Tuesday.

Some things are eternal.

Putting That In Perspective

The age of the universe today is approximately 13.8 billion years per scientists current understanding

The 2⁶⁴-second mark occurs roughly 584.5 billion years after 1970. In other words, the universe would need to survive more than forty times its current age.

At that point:

• The Milky Way and Andromeda have long since merged.
• Most stars have exhausted their fuel.
• Humanity is either unimaginably advanced or a cautionary tale.
• Somebody somewhere is still trying to explain Kubernetes.

The Heat Death Problem

Current cosmological models suggest the heat death of the universe occurs on timescales often estimated at around 10¹⁰⁰ years or longer.

That number is so large that writing it out would require more digits than most people are willing to count.

Compared to that timescale 584 billion years is practically next Tuesday.

So, the good news is a 64-bit timestamp survives comfortably beyond the lifespan of many stars (but, not all, red dwarfs can survive 100s of billions of years or possibly trillions of years, I just looked that up).

The bad news is it still doesn’t survive until the universe completely finishes existing.

Clearly we need a larger integer.

10¹⁰⁰ is called a googol.

Written out in full, it is:

10,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

Or without commas:

100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

• 10³ = thousand
• 10⁶ = million
• 10⁹ = billion
• 10¹² = trillion
• 10¹⁰⁰ = googol

A googol is vastly larger than the estimated number of grains of sand on Earth, but still dramatically smaller than quantities that show up in combinatorics, cryptography, and cosmology. For example, the number of possible 256-bit keys is 2²⁵⁶, which is approximately 1.16×10⁷⁷

So a googol is about 10²³ times larger than the size of the 256-bit key space. So, we’re good there.

The Future Year 584,554,051,223 Problem

Eventually some engineer will write a blog post titled_, “Why did nobody prepare for the 64-bit timestamp overflow?”_

And another engineer will respond_, “_Because we were busy solving the Year 2038 Problem.”

And, yet another engineer will suggest_,_ “Let’s use 128-bit integers.”

Thus, continuing one of computing’s oldest traditions, solving today’s impossible problem by giving it to people who don’t exist yet.

Final Thoughts

The Year 2038 Problem is one of those fascinating examples of how a perfectly reasonable design decision can become a civilization-scale maintenance project decades later.

Nobody expected software written in the 1970s to still influence systems operating in the 2030s.

Yet here we are.

Fortunately, the industry’s transition to 64-bit timestamps largely pushes the next major overflow event to a date so absurdly distant that it occurs hundreds of billions of years into the future.

On a Thursday.

Assuming humanity survives that long, there is an excellent chance that future engineers will discover that some forgotten piece of software still assumes timestamps fit into 64 bits.

And, they will blame us. As tradition demands.

Notes

• AI / GenAI / ChatGPT / etc were not used to generate the text of this article.
• ChatGPT was used to generate the images.
• I used em dashes in my writing before the current GenAI wave was a thing. Not planning on changing now.
• Names have been changed to protect the guilty.
• None of the hostnames or users used in examples actually exist.
• Feel free to post any comments or suggestions below.