The Year 2038 Problem: Y2K on Steroids?

Broken Clock

This is how the world ends: not with a whimper, or a bang, or in fire and ice, but because of a signed 32-bit integer.

Here’s the issue: Many bits of software rely on a 32-bit integer to store time. According to Business Insider, engineers developing computer systems in the 1970s decided to start that integer “clock” at midnight on January 1, 1970. The integer can encompass 2,147,483,647 seconds before it hits a limit and resets or “wraps around” to zero, at which point lots of unpatched systems—now thinking the time is several decades earlier—could begin crashing in not-so-hilarious ways; that “wrap around” date is January 19, 2038 at 3:14:07 UTC.

Click here for troubleshooting jobs.

“Most UNIX-based systems use a 32 bit clock that starts at the arbitrary date of 1/1/1970, so adding 68 years gives you a risk of overflow at 2038,” Jonathan Smith, a Computer and Information Science professor at the University of Pennsylvania, told Business Insider. “Timers could stop working, scheduled reminders might not occur (e.g., calendar appointments), scheduled updates or backups might not occur, billing intervals might not be calculated correctly.”

While it might sound like a (huge) problem for the next generation of computer-science managers to handle, it’s actually a pressing concern, as many systems (such as those owned by the federal government or financial institutions) actively deal with events years or decades in the future. And while consumers tend to update their devices on a regular basis—it’s unlikely that anyone will be using anything 32-bit by 2038, if smartphones and PCs are already migrating to 64-bit systems—enterprise systems have a tendency to linger for years past their underlying technology’s ostensible obsolescence date; updating those systems to sidestep the 2038 problem, if the problem must be solved within the next few years in order to deal with far-horizon events, could present some issues.

So maybe it’s a little extreme to say the world will collapse into chaos because of a bug in system time. In fact, given the overblown panic that greeted the Y2K bug, a little bit of calm is probably in order. But that doesn’t negate the fact that lots of developers and programmers could end up, as with Y2K, engaged in fixing a significant issue.

Related Stories

Image: Big Pants Production/

4 Responses to “The Year 2038 Problem: Y2K on Steroids?”

  1. Randall Stevens

    When I worked on Y2K issues in 1998, we also took this issue into account and extended our C and Java libraries to use a double for the timers. The libraries were sent to many of the vendors we used so they could incorporate the code into their operating systems’ date time algorithms. I even believe that at one time the code was on one of the opensource websites so everyone could use it.

  2. Already hit this one in the Cable Industry, back in 2008. Apparently those “Cable Cards” stuck into the back of the Settop Box have a built in 30 year authorization, set to the 30 years from the date the card was manufactured. This only became an issue with boxes running OCAP/JAVA applications. It seems that when the box booted, OCAP would load this expiration date into a signed integer, and compare it to the current date. Cards manufactured after January 2008 would cause the boxes running OCAP/Java to fail to boot, because the cablecard internal authorization “expired” before 1/1/1970.

    It was fortunate that this showed up in 2008, when these boxes were only running OCAP in early field trials. If the arbitrary expiration date had been only 20 years into the future, things might have waited until 2018 to show up. Something to think about.

  3. Mark Schreiber

    The Y2K bug was not overblown. It is precisely because many people gave dire warnings about the danger that managers took the threat seriously. They fixed the code and tested early. That is why the Y2K bug was a non-event. People need to look at UNIX 32 bit integer clock problem now so it does not become monster change later.