Geek Trivia

Similar To The Y2K Bug, There’s A Looming Date Bug Triggered By The Year?

3000
2038
2020
9999
The Smell Left On Your Hands After Handling Coins Is?

Answer: 2038

The Y2K bug, also called the Year 2000 Problem, was—at its most elementary—a costly-to-fix issue that arose because of the widespread practice of representing the 4 digit year date (e.g. “1985”) as only the last two numbers representing its position in the 20th century (e.g. “85”). It seems like an incredibly simple oversight, but was primarily an outgrowth of programmers focusing on storage economy in early applications and, to a certain degree, not anticipating their applications persisting unchanged for so long. If you’re writing a program to control a power substation or an ATM network in 1981, for example, it’s probably not your default assumption that the same code you put together then will be almost entirely unchanged when the end of 1999 rolls around.

There’s a similar upcoming date issue that hinges on the rollover to the year 2038. This issue is more complex, however, because it’s not as trivial as programmers failing to include 4 slots for the year, but an issue with a widely used standard time library. Here’s why things could be messy (and why it’s easy to fix, thankfully). The majority of C-based programs use the standard time library and the standard time library uses a 4-byte format for time storage. The time in the standard library is determined in seconds, with January 1, 1970 at 12:00:00 a.m. serving as “0” (the first moment), and every second after that is represented as an integer.

If you’re familiar with how computer storage works, you can see where this is going. The limit of a 4-byte storage value is 2,147,483,647. Using the formula in the standard time library, 2,147,483,647 seconds after January 1, 1970 is January 19, 2038. On that day, the integer value will max out, roll over, and result in a negative invalid number and, as a result, any applications using the library will have problems calculating the date.

Fortunately, because this issue is with a widely used library and not hand-coded into thousands and thousands of different applications and systems (as was the Y2K bug), fixing it is relatively easy. Simply recompiling any affected program with an updated library that uses an 8-byte value for time storage (which allows for values up to 9,223,372,036,854,775,807) saves the day. With the new fix implemented, there won’t be an issue with computers and dates for 292.5 billion years.

Image by Andrew Shiva/Wikimedia.