What Is The 2038 Problem?

The Year 2038 problem (also called Y2K38 or the Unix epochalypse) is a software bug in 32-bit Unix-style systems. They store time as a signed 32-bit count of seconds since 1 January 1970; at 03:14:08 UTC on 19 January 2038 that counter overflows and rolls over to a large negative number, sending the clock back to 13 December 1901. Modern 64-bit systems are already immune, but legacy devices and embedded electronics that still use 32-bit time remain at risk.

We live in an organized society, one that is largely founded on community living. This is a shared world, of course, which is why houses can accommodate a number of eclectic family members, why buildings are designed to increase community interactions, why there are multiple checkout lanes in stores to accommodate crowds, and why software is designed to cross platforms and connect different kinds of devices used by all types of users.

A community cannot survive without a shared notion of time, which acts as a critical dimension for civilization, primarily for coordination, organization and communication. The importance of time cannot be overemphasized, as anyone who is regularly late will surely understand.

In the past 50 years, this concept of community living has shifted from the world of atoms to the world of bits, as we have seen more and more of our lives enter the digital realm. Naturally, this is reflected in our translation of time, as every digital device uses standardized time as a reference to carry out instructions and store licenses, among countless other tasks.

If this shared time across devices were to somehow become faulty, our entire digital infrastructure could crumble. How could this come about?

The 2038 Problem

Code is how the digital landscape is designed. It is the way time is kept in computers, so nearly every computer in history has had the capability of keeping time. It is used to develop websites, apps, cars, robots and most importantly, in this case, operating systems.

As computers were being developed, the operating system that became the default in the 1970s was the UNIX system. Almost all operating systems in use today can be traced back to UNIX. It was developed by Bell Labs in the 1960s and the initial release had elements that are still seen today!

The way UNIX kept time was through a 32-bit counting system. This 32-bit system, which remains the standard for modern computers, has been counting forward from 00:00:00 UTC January 1st 1970. This counter has a finite amount of seconds that it can count up and down to +(2³¹ – 1) and -(2³¹ – 1), which is equal to 2,147,483,647 seconds going both ways. 2 billion seconds may seem like a lifetime (and it is), but this system will still count its last second precisely on 03:14:07 19^th January 2038.

The counter will then begin to count from the negative scale, once this date comes to pass, causing the computers to reset to December 13th 1901, leading to all kinds of errors in every modern 32-bit computer.

This is the 2038 problem, which will mark the end of UNIX time and subsequently the UNIX epoch. It could also cause a lot of chaos if left unchecked.

Why Does The Clock Jump Back To 1901?

Rolling back to 1901 sounds oddly specific, so why that year, and not simply back to 1970 where the counting began? The answer lies in how computers store negative numbers. A signed 32-bit integer sets aside one of its 32 bits to record the sign, which leaves it able to represent whole numbers from -2,147,483,648 up to +2,147,483,647. Unix time treats that value as a running count of seconds measured from the epoch at 00:00:00 UTC on 1 January 1970.

The trouble is what happens at the very top of that range. Under the two’s complement scheme that nearly all computers use for signed whole numbers, adding one to the largest positive value does not produce a bigger number. Instead it flips the leading sign bit and wraps around to the largest negative value. So the instant the clock ticks one second past 2,147,483,647 (03:14:07 UTC on 19 January 2038), it lands on -2,147,483,648. A negative count of seconds points to a moment before the epoch, and 2³¹ seconds before 1 January 1970 works out to 20:45:52 UTC on 13 December 1901. The clock has not really travelled through time; it has simply run off the end of its number line and reappeared at the far end.

How It Could Affect The World

Almost every piece of equipment today contains a microprocessor that runs on this system. Embedded systems in factory machinery and transportation systems, such as those found in cars and airplanes, are used to automate certain processes and coordinate with other parts of the system. For example, cars use onboard computers to monitor electronic stability control, traction control, the GPS system, braking systems, etc. When the UNIX epoch ends, these machines could malfunction, harming the human users or onboard passengers during the possible system crash.

Licenses today use dates to verify and regulate users, so a fault in this dating system would result in the termination and overall malfunction of the subscription records that the company uses, thus harming many users. This is the same for any service that uses a timestamp for authenticating and renewing user access to their work and private document; it will result in the inaccessibility of these documents and financial information once the UNIX epoch comes to an end.

The effects from this problem aren’t only going to be felt after 2038, but also much earlier, as many apps and websites use future dates for scheduling, managing hedge funds, etc.

Has The 2038 Bug Already Bitten?

If 2038 still sounds comfortably far away, here is the unsettling part: the bug has already surfaced in the wild, years ahead of schedule. It does not politely wait for the calendar to reach 2038. It bites the moment a piece of software tries to work with a moment in time that sits past the 32-bit ceiling.

The first well-known case appeared in May 2006 in AOLserver, a widely used web server. Its database timeout carried a default of one billion seconds, a span so long that it effectively meant “never”. Unfortunately, one billion seconds before the 2038 cutoff falls on 01:27:28 UTC on 13 May 2006. From that instant onward, every timeout the server calculated landed beyond the 32-bit limit, overflowed into a negative number, and was read as a date in the past. Requests appeared to “time out” the moment they arrived, and the software crashed until operators manually dialed the timeout back down.

More recent episodes keep the pattern alive. Security certificates set to expire after 2038 have failed to validate on 32-bit systems, and on 1 January 2022 Microsoft Exchange’s malware scanner stopped delivering email around the world when a date-stamped version number (2201010001) sailed past the very same signed 32-bit ceiling of 2,147,483,647. The 2038 problem, then, is not purely a future event. It is a slow leak that has already sprung in more than one place.

Why 2038 Could Be Harder To Fix Than Y2K

The obvious comparison is the Year 2000 bug, or Y2K, when the world held its breath over two-digit year fields flipping from 99 to 00. That scare passed with barely a hiccup, so it is tempting to assume 2038 will be just as quiet. The two problems, however, are not quite the same animal.

Y2K was a base-10 problem: programmers had stored years as two decimal digits to save memory, and the fix usually meant widening a date field inside business software that was actively maintained. The 2038 problem lives one layer deeper, in the base-2 (binary) way computers count seconds, and it tends to hide in places nobody is maintaining.

That is the real difficulty. Y2K was concentrated in mainframes, databases and desktop applications that companies could audit and patch under a coordinated, well-funded and heavily publicized effort. The 32-bit clock, by contrast, is baked into countless embedded systems (industrial controllers, medical devices, cars, routers and sensors) that were built to run untouched for decades and often have no practical way to receive an update at all. No single authority is responsible for all of them, and because Y2K ultimately felt like a false alarm, there is a genuine risk that the world under-prepares for the sequel.

Possible Solutions For 2038 Bug

The 2038 bug is similar to the millennial bug (the Y2K scare in the year 2000), but it’s potentially more damaging because there are far more devices in much more diverse types of electronic equipment today. Unfortunately, there doesn’t seem to be one solution that works as a universal remedy for this problem.

For those devices connected to the internet, a simple software update could solve this issue, so the majority of computing devices are going to be fine, as the IoT revolution has linked more and more devices to the internet (computers, laptops, tablets, smartwatches, household appliances, cars etc.).

Better computing systems are already replacing the 32-bit system, as 64-bit computers are being used in the new electronics coming out today. They are poised to solve this problem for a much longer time, a time far greater than the age of the universe itself! These systems will be able to keep time for 20 times the current age of the universe, which comes to around 292 billion years!

The most problematic devices are going to be those that aren’t connected to the internet and that can’t be updated through a software patch. Engineers have been chipping away at this for a while: as of Linux kernel 5.6 (released March 2020), 32-bit Linux systems support 64-bit time_t values, and major C libraries (musl, glibc with the _TIME_BITS=64 option) now allow legacy 32-bit applications to be recompiled with 64-bit timestamps. Databases like MySQL, PostgreSQL and SQL Server have also updated their timestamp formats. The danger now sits mainly in embedded electronics that aren’t connected to the internet and can’t be easily updated, the kind of devices that quietly do their job for decades.

In any case, there’s no need to panic, as this is a widely discussed issue in the computer science industry that is constantly being worked on. Any actual problems that arise as a result in 2038 will be perfectly manageable–so don’t worry!