Bach Seat

Rebecca Borison at the BusinessInsider asks who remembers the 1999 panic about the Y2K crisis. In 1999, Y2K looked as if it might derail modern life when computers because the glitch would reset computers to Jan 1. 1900, rather than Jan. 1, 2000, because computers only used two digits to represent a year in their internal clocks.

Now it déjà vu all over again, BI reports there’s a new, even bigger global software coding fiasco looming.  A huge amount of computer software could fail around the year 2038 because of issues with the way the code that runs them measures time.

Once again, just like with Y2K every single piece of software and computer code on the planet must now be checked and updated again. That is not a trivial task according to the author. In 2000, we bypassed the Y2K problem by recoding the software explains Ms. Borison. All the software — a fantastically laborious retrospective global software patch.

Disruption to the tech industry

Although Y2K was not a disaster, it was a massive disruption to the tech industry at the time. Virtually every company on the planet running any type of software had to find their specific Y2K issue and hire someone to fix it. Ultimately, Y2K caused ordinary people very few problems — but that’s only because there was a huge expenditure of time and resources within the tech business.

The 2038 problem will affect software that uses what’s called a signed 32-bit integer for storing time. The problem arises because 32-bit software can only measure a maximum value of 2,147,483,647 seconds. This is the biggest number you can represent using a 32-bit system.

When a bunch of engineers developed the first UNIX computer operating system in the 1970s, they arbitrarily decided that time would be represented as a signed 32-bit integer (or number), and be measured as the number of milliseconds since 12:00:00 a.m. on January 1, 1970.

Glitch says it’s 1970 again

On January 19, 2038 — 2,147,483,647 seconds after January 1, 1970 — these computer programs will exceed the maximum value of time expressible by a 32-bit system using a base 2 binary counting system, and any software that hasn’t been fixed will then wrap back around to zero, thinking that it’s 1970 again.

UNIX time coding has since been incorporated widely into any software or hardware system that needs to measure time.

BI spoke with Jonathan Smith, a Computer and Information Science professor at the University of Pennsylvania for confirmation. The professor confirmed the Year 2038 is a real problem that will affect a specific subset of software that counts on a clock progressing positively. He elaborated:

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 … 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

The article concludes that we all need just to switch to higher bit values like 64 bits, which will give a higher maximum. In the last few years, more personal computers have made this shift, especially companies that have already needed to project time past 2038, like banks that need to deal with 30-year mortgages.

Apple (AAPL) claims that the iPhone 5S is the first 64-bit smartphone. But the 2038 problem applies to both hardware and software, so even if the 5S uses 64 bits, an alarm clock app on the phone needs to be updated as well. (If it’s using a 32-bit system in 2038 it will wake you up in 1970, so to speak.) So the issue is more of a logistical problem than a technical one.

rb-

The tech industry’s response to Y2K suggests that they will mostly ignore the 2038 issue until the very last minute when it becomes to ignore.  Another example of the pace of global software updates is that a majority of ATM cash machines were still running Windows XP, and thus vulnerable to hackers even though Microsoft discontinued the product in 2007.

Fortunately, the 2038 problem is somewhat easier to fix than the Y2K problem. Well-written programs can simply be recompiled with a new version of the C-library that uses 8-byte values for the storage format. This is possible because the C-library encapsulates the whole time activity with its own time types and functions (unlike most mainframe programs, which did not standardize their date formats or calculations). So the Year 2038 problem should not be nearly as hard to fix as the Y2K problem was.

Related articles

• The Upcoming 2038 Date Bug (drdobbs.com)

Ralph Bach has been in IT long enough to know better and has blogged from his Bach Seat about IT, careers, and anything else that catches his attention since 2005. You can follow him on LinkedIn, Facebook, and Twitter. Email the Bach Seat here.