The Real Millennium Bug

Jan 1st 2000. Midnight

Many people reading this article will remember the hysteria that surrounded the so called Millennium bug. For those that may not be aware, this was a perceived problem with the way dates are stored in computers that supposedly was going to unleash havoc on the world when the date changed from 31/12/1999 to 1/1/2000. The problem was supposedly related to the use of 2 digits to store the year in some systems, resulting in the year going from 99 to 00.

At the time there were predictions of apocalypse surrounding this. Stock control systems were predicted to go haywire resulting in empty shops. There was concern over the functioning of the National Power Grid and numerous other scare stories. I even recall reading an article suggesting that it would be unwise to fly over midnight on millennium night as the planes might either flip over and fly upside-down or spiral out of control and crash.

As someone involved in the computer industry I was highly sceptical in regard to these preposterous claims. I could envisage some small glitches occurring as a result of this, but not a meltdown of civilisation in the way that was being predicted by some.

But companies and government alike bought into the idea that the issue was real and that something needed to be done to ameliorate the issues before the millennium. Personally, I am of the opinion that the whole thing was played up by people with a vested interest. There is no doubt that a lot of work was generated “fixing” old systems that were assumed to be broken. Many COBOL programmers came out of retirement on high contract rates to fix old systems that were still in use.

Within my own company the whole thing was taken extremely seriously. I myself was required to perform various code audits prior to the date. For the period of the millennium itself there was a “task force” assigned. This was a team of some 20 or so employees who agreed to work over the millennium – the idea being they would somehow sort out customer issues should they arise. The team had to be on company premises for this, and were placed in a “war” room complete with backup diesel power generators.

I was not on this task force, but I was on-call. Because of the fact that it was the Millennium, the company were paying quite handsomely for all of this. I actually did receive a call-out on the evening of the millennium, at about 7PM. All this turned out to be was a query from one of the guys in the war room who wanted to understand some particular aspect of a particular utility that he thought might be affected by the millennium issue. It took me about 10 minutes to explain how it worked and why it was not a problem. But that was still a call-out and because of this and the fact I was on call all night I did receive a rather nice payout (amounting to 4 figures) with my next paycheque. I think the guys in the war room earned themselves really big money.

As we all know, the millennium passed without the world coming to an end, or even without anything untoward happening. The power did stay on and planes did not fall out of the sky. The only thing I recall hearing about, ironically, was about a big electronic clock setup specifically for the millennium, which was displaying the time and date for the assembled crowds. Unfortunately I cannot recall where in the world this was, but I do know that at the moment of the millennium the time ticked over to…. 1st Jan 19100

19th Jan 2038 03:14:08

Now this is the date when there really might be an issue. UNIX systems store time information as a numeric value. This value is equal to the number of seconds that have elapsed since 1st Jan 1970. 1)

The correct data type for storage of a UNIX time is time_t and on a modern system this is almost certain to be a 64 bit variable. A 64 bit variable can store an astronomically large value, and any systems storing time in this way will be safe from any overflow issues.

However, prior to today’s 64 bit systems, 32 bit systems have been prevalent, and on these systems time_t has commonly been defined as a 32 bit integer. It is also highly likely that there will be a lot of lazy code around that uses int instead of time_t for the datatype. This is a real problem because int will normally still be a 32bit variable even on a 64bit system.

The maximum value of a 32 bit integer before overflow occurs is 2147483647. If you work this out as a number of seconds since 1st Jan 1970 you end up with, you’ve guessed it, the 19th Jan 2038 at 03:14:08 (GMT). When the time ticks over to the next second, because of the overflow it will suddenly become a large negative number of -2147483648. This corresponds to a date of Friday 13th December 1901 at 20:45:52 GMT. Oops. Perhaps there is a justifiable reason for Friday the Thirteenth to be considered unlucky after all!

Some readers may be familiar with unsigned variables. This type of variable can only stored positive values which means it does not need a sign bit. An unsigned integer has all 32 bits available for the numeric value instead of the 31 bits available to normal (signed) integer. As a consequence a much larger number can be stored. If time_t were defined as an unsigned integer then the date at which the problem occurs would be much further into the future – in the 22cd century. However, it has long been convention for time_t to be a signed integer. This is a hangover from the early days of UNIX when it was thought it might be necessary to manipulate some dates in the recent past (eg in the 1960s). For this a negative UNIX time was needed.

So you see the potential problem – but what issues will it cause? Potentially very many more problems than for the original millennium bug. Instead of being an issue related to how dates are displayed, this relates to the underlying understanding of the time within the system. Things really could go haywire and the sorts of problems envisaged with the original millennium bug are far more likely to emerge. Stock control systems I can easily see being affected, and it is easy to see how it could hit reporting and accounting systems. But time is embedded into areas you would not immediately think of – GPS navigation for example, so perhaps the thought of the planes falling out of the sky is not so far fetched after all. There are an awful lot of things that could genuinely just stop working.

I will certainly be retired long before we get to this. Maybe I will come out of retirement for a few months in the run up to the event to fix issues in old UNIX/C systems – at premium contract rates, of course!


QR Code
QR Code the_real_millennium_bug (generated for current page)