Back in 1998/1999 I was working for a logistics company called Schnellecke. They were responsible for supplying Volkswagen with their required car parts as per the Bill of Materials and materials planning for each Volkswagen car (including at that time the new Audi A4 which was also manufactured in the same plant). I can remember an influx of IT personnel (you know, the alien type) that sat behind a terminal and started to furiously type away, doing goodness knows what.
One day, I asked them what the hell they were doing. Man, the doom and gloom that spewed forth was something of epic proportions. I mean, not even a doomsayer could top that! Bank accounts would be cleared out, planes would fall from the sky, nuclear missiles would launch, medical Intensive Care machines would stop functioning, stock markets would crash and life as we know it would revert to the stone ages. Sheesh, that guy had me at “bank accounts would be cleared out”. After that, the rest seemed frivolous.
People started stocking up on bottled water and food. According to the New York Times, Rev. Jerry Falwell even prophesied the following “I believe that Y2K may be God’s instrument to shake this nation, humble this nation, awaken this nation and from this nation start revival that spreads the face of the earth before the Rapture of the Church.”
Well it turns out that the very reverend mr. Falwell didn’t count on the army of IT professionals waging war on an unseen IT bug which was 40 years in the making. I say that because the human race knew about Y2K for almost 40 years. You might wonder why Y2K was a problem to begin with.
Using only two digits to represent the year made sense back in the 60’s. Memory constraints of current computers at the time necessitated the use of the two digits. Programmers also didn’t think that their programs would last that long. I guess nobody realised the power of Cobol on which many modern day banking systems, in part, still run on. Don’t believe me? How is this for a statistic: “There are over 220 billion lines of COBOL in existence, a figure which equates to around 80% of the world’s actively used code.” That is according to Jeff Atwood in a post he wrote in 2009. Vince, who is a friend and colleague of mine will enjoy hearing that COBOL stat I’m sure.
So after all was said and done, we are still around and nothing disastrous took place on new years day in 2000. (Excepting for a multitude of hangovers etc.) Can you remember where you were at the turn of the millennium? I was in Knysna, at the lookout point on the Heads. What an awesome view and what an awesome sight that night with all the fireworks going off. I can remember looking up at the night sky watching all the fireworks and Y2K being the last thing on my mind. In fact, Y2K has been called the most expensive non-event in human history, costing between $300 – $600 Billion.
But guess what, revenge is a dish best served ice cold. If Y2K was a sentient entity, I’m sure that it would be quite upset with the human race. So upset in fact that it would take endless amounts of pleasure in the occurrence of the Year 2038 problem. We seem to have done it again.
Year 2038 Problem
The year 2038 problem could result in some software to fail sometime close to the year 2038. If your software stores system time as a signed 32-bit integer, and interprets this number as the amount of seconds since 00:00:00 UTC on Thursday, 1 January 1970; your app will be affected. Because the integer can only hold a set amount of digits (data) it means that the maximum time that it can represent is 03:14:07 UTC on Tuesday, 19 January 2038.
Any time beyond that will “wrap around”, having the software store it internally as a negative number. Software will then interpret this negative number as December 13, 1901 (which is a Friday – Friday the 13th?) instead of January 19, 2038. As per Wikipedia: “This is caused by integer overflow. The counter ‘runs out’ of usable digits, ‘increments’ the sign bit instead, and reports a maximally negative number (continuing to count up, toward zero)“. In other words, affected software will start to make calculation errors. Not a good thing when calculating the exchange rate etc.
Year 2038 Problem – Fix
So what do we do to fix the year 2038 problem? I have read a few suggestions ranging from ‘It’s impossible’ to ‘Change the data type’. The simplest would seem to be to switch to 64 bit computing. Wikipedia obviously has a nice article on the subject. The real issue is obviously what do we do with all the existing software out there on 32 bit systems? I would really like to hear any opinions and thoughts on the matter. So feel free to join the discussion below by leaving a comment.