The Millennium Timebomb

It has been called the biggest threat to computing ever discovered and it sounds just too stupid to be true. It is referred to as the Year 2000 Problem or the Millennium Bug. It relates to the way computers have traditionally stored dates and it could cause a whole heap of trouble.

The basic problem is that software running on many computers uses only two digits to designate the year. This is a standard format we all know - MM/DD/YY - where "1996" is stored as "96" and "2000" as "00". This works fine when dealing with dates between 1900 and 1999. The problems arise when computations involve dates outside of this range.

In 1994 an invitaion to enroll in kindergarten was sent to Mary Bandar of Winona, Minnesota. Since she had been born in 88, software used by the local board of education calculated that she was turning five this year and it was time for her to start school in the fall. The only problem was that she was born in 1888. Mary was 105 years old!

Or let's take someone who was born in 1972: to calculate her age today in 1996, a computer program would subtract 72 from 96 and correctly determine she was 24. But what if the same software tried to calculate her age in the year 2000 which is stored as "00"? It would subtract 72 from 00 resulting in -72 years old. In fact, any calculations that involve spans of time can be thrown off by this error.

It's a fairly simple problem to understand and doesn't sound terribly ominous on the surface but there is an incredible amount of software in use around the world that will encounter problems related to the century date change and estimates of the costs to fix it all range as high as US$300 billion. It's not that the solution is particulary technically challengin; all that needs to be done is to replace the two digit year with a four digit year; that's what would allow software to distinguish 1900 from 2000. The high cost estimates derive from the huge amounts of time needed for programmers to dig through all the running computer code - millions of lines of it for some organizations - to see just what parts of what programs need to be changed and then the long hours of tedious work actually making the changes to the software and the structure in which the data are stored. As a sidelight, software changes on such a massive scale will almost certainly tend to introduce bugs into software that have been running perfectly for years. And there are only 40 months left.

Problems are already surfacing and having to be dealt with. Five year auto loans that extend beyond the century change, 15 and 30 year mortgage calculations and long term insurance problems can all be affected. And not just information systems are at risk. Any electronic equipment using a calendar as a timing device, such as traffic lights that change on weekends, is at risk. The same holds true for many security systems, elevators and heating and air conditioning systems that run on timers. When we roll over to 2000, many of these devices will be hopelessly confused or just stop working, with perhaps dire consequences.

How could we have gotten into this mess? Actually, the problems are primarily with software written in the 70s, 80's and earlier; most programming done since the mid eighties has effectively addressed this problem. However, back in the early days of computing, most programmers never considered their software would continue to be used more than 10 or 15 years so the millennium problem was not considered a factor. And back then the cost of computer storage space was hugely more expensive than it is today. Adding two century digits to a date field for a 100 million record file adds at least 100 megabytes of storage requirements and disk drives in those days were costing many thousands of dollars for just 15 - 20 megabytes. So there was a powerful economic incentive to squish as much data into as little space as possible and trimming two digits from the year was a cost efficient approach.

While businesses are more likely to upgrade their systems regularly, many government systems are still chugging along on 60s era mainframes running software that is twenty or thirty years old or older. And although even some modern computer systems have trouble with dates beyond 1999, the problems are greatest with older "legacy" systems and these will be the costliest and most difficult to fix.

Since older goverment computer systems seem to be most succeptible to causing problems when working with dates, it would seem there would be a rush to address the issue. In fact, it has been difficult to sell lawmakers on the need to hurry a solution. For one thing, the whole problem can sound somewhat frivolous and not particularly dire at first glance. But, the primary difficulty is that very few governing bodies have the necessary funding built into their budgets. As a result, there appears to be a widespread sense of denial surrounding the issue.

Some estimates are that less than half of all organizations will be year-2000 compliant by the turn of the century, and the percentage of state and local governments that have solved their millennium problems will be even lower. Some entities, however, have faced up to the enormity of the task at hand. Nebraska, for instance, has diverted two cents per pack from their state cigarette tax in an attempt to raise $11.5 million earmarked for their conversion efforts. The Social Security Commission started working on the problem in 1989 and has $30 million allocated for the task.

Others, such as Napa County in California, have decided it is cheaper to junk their older systems and start from scratch. They recently upgraded their entire system at a cost of $2.7 million but now have payroll, personnel and all their other programs capable of manipulating four digit years. Massachusettes was faced with the choice of upgrading their 20 year old systems at a cost of $5 million but opted, instead, to pop for a new one costing $15 million; sort of like deciding it wasn't worth putting a new transmission into a 20 year old car.

An entire industry has arisen in response to the year 2000 problem. For the right price these outfits will do their best to fix the code in the time available. There are more players entering all the time as it become obvious that there is a ton of money to be made correcting all the affected software. There are definitely voices of dissent, though. Some describe the entire mess as the focus of a huge and unique racket and say that the problem has been grossly exagerated, partly because of the certain mystique linked with the millennium itself. Whatever the case, there are certainly many opportunities for errors large and small to start creeping into the date related calculations done every day and it seems that the organizations that can deal effectively with the situation will suffer the least. And we will still have to come to grips with the situation we face 8,000 years from now when the four digit year overflows.