The 2038 Problem Is The Next Y2K Bug – So How Ready For It Are We?

The fear was that, as ‘99 clicked over into ‘00, computers would be unable to parse that the century had changed; the date would be reset back to 1900, and computer-reliant systems worldwide would crash and burn. The result? Anything from “a few amusing mistakes on electronic calendars” to “the literal collapse of civilization as we know it”, depending on who you asked.

In the end, of course, the new year ended up being fairly uneventful – thanks in no small part to a widespread and concerted effort behind the scenes to avoid disaster. And that was that, right? Smooth sailing from then on?

Wait – there’s a sequel?

What is the 2038 problem?

January 19, 2038: the day that time ends. At least, if you’re a computer using 32-bit Unix time – which almost all of them do. 

“A signed 32-bit integer can only store numbers from –2147483648 to 2147483647,” explains Tanium, a cybersecurity and systems management company headquartered in Kirkland, Washington. “This means the highest timestamp these systems can handle is 2147483647, which corresponds to January 19, 2038, at 03:14:07 UTC.” 

Those numbers aren’t random – as arbitrary as 2,147,483,648 may seem to human eyes, for a computer working in base-2, it’s a big milestone: it’s when the clock hits 100,000,000,000,000,000,000,000,000,000,000. For a 32-bit system, that’s simply too many digits to keep hold of – so the counter does the only thing available to it, and goes all the way back to the beginning again.

“The timestamp will overflow and become a negative number, which will cause the date and time to be wrong,” Tanium explains. “For example, the timestamp for [03:14:08 UTC] January 20, 2038, in Unix time is 2147483648. Since this is not a valid timestamp using the Unix format, it will overflow and become –2147483648, which corresponds to December 13, 1901, at 20:45:52 UTC. This is the year 2038 bug.”

Should we be worried?

After all of the hullabaloo around the Y2K problem, you’d hope we would have learned our lesson when it comes to preparation. After all, we’ve known about the 2038 bug since at least 2006, when a similar problem hit the software supporting the AOL’s web server – surely, 32 years is more than enough time to figure out a fix? 

In fact, there’s a pretty easy workaround to the 2038 problem, and it’s staring us right in the face: “The solution is to transition to 64-bit time support,” wrote Paul Budde, CEO of independent consultancy company Paul Budde Consulting, in Independent Australia back in 2022. “With 64 bits, there is more than enough room to store time values far past the foreseeable future, even if high-resolution (nanosecond-based) time values are used.”

Sixty-four may not seem all that much bigger than 32 – but when we’re dealing with exponents, it’s the difference between “13 years” and “about 21 times the age of the universe”. Upgrading to the larger storage system would, it’s fair to say, punt the problem so far down the road that it may as well be entirely solved. So, have we made the switch en masse? 

Well… no. “Several database types, including relational and NoSQL databases” still rely on 32-bit time, Tanium points out, as do any programs written in languages based on C, such as C++ and PHP. Devices running Windows, Linux, Android, or iOS might be at risk, they note, as well as “medical devices, industrial control systems for facilities like power stations, transportation systems, cars with onboard computer systems that monitor electronic stability control and traction control, routers, switches, sensors, sensors, and IoT [Internet of Things] devices like smart appliances.”

All in all, it has the potential to be extremely disruptive. So, how ready for it are we?

Are we ready for the 2038 bug?

It’s difficult to say exactly how ready we are for 2038 – as newer operating systems are rolled out, many are given 64-bit integer time as standard these days. But the bigger problem is with already-existing systems: making the switch from 32- to 64-bit is, for source-based operating systems, “nowhere near trivial,” wrote Michał Górny, developer for the Linux distribution Gentoo, in a 2024 blog post on the topic.

“Above all, we are talking about a breaking ABI change. It’s all-or-nothing,” he wrote. “If a library uses time_t in its API, everything linking to it needs to use the same type width […] mixing time32 and time64 programs and libraries can lead to horrible runtime bugs.”

Basically, suddenly switching over from 32-bit to 64-bit timestamps would leave a bunch of already-existing programs struggling to understand the new system. It would be like if you were suddenly transported back to Medieval England, and wanted to communicate with the locals: technically, you’d be speaking the same language, but practically? You wouldn’t totally know what was going on at any point.

And that’s only the beginning. We’ve had – and still have – lots of time to prepare for the 2038 problem, and when it hits, “all current computer systems will have been upgraded well before that time,” Budde predicted. “However […] most of these problems are going to be in old programs that no one ever remembers to update and test,” he cautioned – “it[’s] not something that computer engineers would want to leave to the last minute, as happened with the Y2K issue.”

Even if every 32-bit time reliant system is found and upgraded, the ripple effects from such wholesale changes “will need to be mapped first and then thoroughly researched to find the appropriate solutions that prevent unwanted side effects,” Budde cautioned. “And in turn, these solutions could create their own side effects.”

So, uh… yeah. Fingers crossed, eh, folks?

Learning from our mistakes

Listen: let’s be optimistic. Say we completely solve the 2038 problem, and all associated ripple effects, and no computerized system has even a blip at 03:14:08 on January 20, 2038. Can we all just breathe a sigh of relief and forget the whole thing?

Well, we can – but we probably shouldn’t. Only a few decades later, we’ll be facing the same thing again: on February 7, 2106, at 06:28:15 UTC, the problem will hit all those systems storing time as an unsigned 32-bit integer – that is, using the same number of digits, but not giving any of them over to negative numbers.

Fast forward roughly the same time period again, and Windows is facing its own version of the bug: “Windows NT uses a 64-bit integer to track time,” notes HowStuffWorks. “However, it uses 100 nanoseconds as its increment and the beginning of time is January 1, 1601, so NT suffers from the Year 2184 problem.”

Past that, there’s a 2262 Problem, a 2262 Problem, and even a 2446 Problem, all related to past programmers’ assumptions of how long we’d continue to use protocols invented in the mid-20th century. We’d say it was short-sighted of them – but let’s face it: pretty soon, we’re going to have much bigger problems to deal with in any case.