You are here
Home > Technology > Y2K Bug Revisited In The Year 2038 Problem

Y2K Bug Revisited In The Year 2038 Problem

Fallback Image

Year 2038 Problem and y2kBack 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.”

Y2K how programmers see usersWell 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.

References: Wikipedia, NYTimes, Izifunny, NewtonPoetry

Dirk Strauss
Dirk is a Software Developer and Microsoft MVP from South Africa. He loves all things Technology and is slightly addicted to Twitter and Jimi Hendrix. Apart from writing code, he also enjoys writing human readable articles. "I love sharing knowledge and connecting with people from around the world. It's the diversity that makes life so beautiful." Dirk feels very strongly that pizza is simply not complete without Tabasco, that you can never have too much garlic, and that cooking the perfect steak is an art he has yet to master.

Similar Articles

  • VincevanZyl

    Y2K was a non-event BECAUSE of all the effort expended to mitigate the issues: things like (out of desperation) century offsets (which assumed years 50 to be 1900 + year), database redesigns where possible, and so on. Many people made a fortune out of the poor design which resulted from the high cost of data storage in early years. Apparently there were even companies who motivated their teams in strange ways (such as an airline in Japan who told their senior management they WILL be flying in an airplane at the stroke of midnight to test that they had done enough to ensure that the avionics were Y2K compliant… nice move).

    COBOL is like a bad reputation – no matter what you do, it sticks around forever, so for a smile (and for the edification of COBOL developers everywhere):

    The story is told of a developer who was not convinced that enough had been done to prevent the chaos of Y2K, and having made a fortune in the process, arranged to have his body frozen, to be re-wakened in 2002, after all the ensuing chaos should have been sorted out. When he awoke, it was in a white room, where the light appeared to come from the very walls instead of fittings, and people in strange white clothing peering at him and joyfully shouting “It worked!!! He’s awake!!!”. Confused he asked what had happened, and was told that the clock on his cryogenic chamber was not Y2K compliant, and had failed. Instead of being 2002, it was actually 9998, and it had taken them many years to figure out how to safely wake him up. Due to of the risks involved, they had delayed waking him until now.

    “So then WHY have you woken me NOW?” he asked…

    “Well,” came the reply, “all our dates are stored in 4 digits, the year Y10K is upon us, and it says on your CV that you know COBOL”!!!!

    • Dirk Strauss

      LOL! Awesome story!!!! I love it!!!