Description of the Year 2000 problem
Adapted from Who's Afraid of More C++?
ISBN: 0-12-339104-0
By Steve Heller
AP Professional, July 1998
Used by permission of the publisher
Terror in the Year Zero
Memory (that is, RAM) and disk storage were much more expensive in the past than they are today. For this reason, a very large number of programs written before the 1980s, and even some written since then, have employed a space-saving "shortcut" when dealing with dates. To be precise, these programs use a 2-digit number to represent the year portion of a date in the form "YYMMDD" (that is, two digits for the year, two for the month, and two for the day), which saves storage compared to storing the entire year as in the form "YYYYMMDD". I'm sure this seemed like (and may have even been) a good idea at the time, but it has turned out to be a very expensive way to save money, because, contrary to expectations at the time they were written, many of these programs are still in use, and none of them will work much longer, if indeed they haven't already started to fail. How will these programs fail? There are many possible ways, but I can think of a few that are certain to occur.
- Interest calculations such as for credit card debt, which depend
on the number of days since the last payment, will calculate the
interest incorrectly.[1]
- Automated inventory systems that calculate the number of items to
order based on criteria such as the average of the last 6 months'
orders will compute the ordering amount incorrectly.
- Programmed maintenance schedules for automobiles, commercial
building control systems, and the like, that control the availability
of the device based on how long it has been since the last maintenance
was done will decide that the device has not been maintained for a
long time even though it has (or that it has been maintained when it
hasn't). For example, many elevators are programmed to stop working as
a safety measure if an excessive amount of time has elapsed since they
were last maintained.
- Other such "embedded" controller systems that manage the flow of
materials through plants, pipelines, electrical distribution networks,
oil tankers and the like will do their jobs incorrectly.
The people responsible for these defective programs can't really claim
that these problems are beyond their control; after all, the fact that
the year 2000 was coming has been known for quite some time. Given
this, surely the companies that are affected by this problem will have
everything fixed by January 1st, 2000. Won't they?
I'll Think about It Tomorrow
I'm afraid that's not going to happen. The first reason is that, as I
write this in mid-1998, many companies haven't even started working on
the problem! How did such a vital task get put off until it's too
late? That's easy to explain. Pretend you are a reasonably competent
manager working for Amalgamated Conglomerate. Here are some of the
major characteristics of the project we need to do:
- Its success is absolutely essential to the survival of the company.
- It is mind-numbingly boring, tedious work, which implies even
higher turnover than usual in software projects.
- It is completely invisible to the customer, who has undoubtedly
requested a_number of new features that will have to be postponed to
work on this project.
- The skills learned are completely worthless when the project is over.
- The deadline cannot be postponed by even one day.
Now I want a show of hands: Who would like to lead this project? As I
suspected, I'm not likely to get very many volunteers.
But why should fixing these problems be so difficult? All we have to
do is to change the date fields to use four digits rather than two for
the year portion of the date, and change all of the code that refers
to those date fields. How hard could that be?
Much harder than it would be if modern software design rules had been
applied. The problem here is that everyone wrote their own date
calculation routines, and used these date fields throughout their
programs, often without documenting how they worked or where they were
used. Some of these programs are thirty years old, and the people who
worked on them are long gone, if they're even still alive. The only
way to fix these date problems is to go over the code, line by line,
searching for any reference to dates. Once each such reference is
found, it has to be fixed. Unfortunately, the chance of introducing a
new error when fixing an old one is not negligible; in fact, it can be
quite high. This means that extremely thorough and careful testing is
needed to try to ensure that new errors haven't been introduced in
this process.
Okay, so it's a lot of work. But these companies have had plenty of
time to fix it, so why haven't they done it by now?
In the Long Run, We Are All Dead
There are a number of excuses, but the truth of the matter is this:
Although the company desperately needs these programs to be fixed,
it's not in any individual manager's interest to be in charge of the
project. And since there isn't any "company" to do it if the
individual managers don't want to, it doesn't get done.
In my opinion, this situation has exposed a serious flaw in the
structure of corporations: Within a corporation, there is no market.
This means that while the benefits of fixing this problem would have
accrued to the entire company, the difficulties would have fallen on
the individual managers who were running the projects. Therefore, the
most sensible course of action from the point of view of the
individual manager was to duck responsibility; with any luck, he or
she would have retired or at least moved to another company before the
day of reckoning arrived.
Was there any way of preventing this outcome? Yes, but it would have
required managers to act as entrepreneurs rather than employees. That
is, if companies were organized as a number of autonomous groups who
bought and sold one another's products, then anyone who could fix bugs
like the Year 2000 problem would have been able to make a good living
doing so. Because of the laws of supply and demand, the fewer people
who wanted to work on such projects, the more money each one would
make. As a result, the rewards for fixing the problem would be
commensurate with the difficulty and risk of taking on the project, so
we wouldn't be in the mess that we're in today.
Of course, it wouldn't be much fun if the banking system collapsed (to
take one example), but that wouldn't be fatal, at least in the short
run. But what about the "embedded systems" that control
power, sewer, water, and the like? If they aren't fixed in time, the
results will be much worse than getting a very confused bank
statement.
What might happen from one or more embedded system failures? I can't
predict the consequences in detail, but I think it's pretty obvious
that big cities aren't likely to be very good places to live if the
industrial infrastructure (power, water, telephone) isn't working.
Are there any benefits to be gained from this mess? I can think of
some. Of course, one attractive prospect is the probable collapse of
certain large universally hated bureaucratic organizations under the
weight of massive program failure. If that occurs, it will be worth
the estimated $600 billion price tag for fixing the problem in
companies around the world. It's also within the realm of possibility
that this fiasco will encourage a serious reconsideration of the
reward and penalty structure of whatever corporations are still in
business after January 1st, 2000.
To return to my main page, click here
An example for those not afraid of arithmetic
To see how these calculations might be incorrect when the year 2000
rolls around, let's take the first one of these as a more detailed
example. Suppose that we have a program that calculates the interest
due on a credit card in the following (somewhat oversimplified)
way:
- Calculate the "day number" of the previous payment by the following procedure:
- Multiply the year number by 365.
- Add the day of the month.
- Add the day number of the beginning of this month. This is the number of days in the year before the first of the month. This number is 0 for January, 31 for February, 59 for March, and so on.
- Calculate the day number of the current payment by the same procedure as above, substituting the correct values for the year number, day of the month, and day number of the beginning of the month.
- Subtract the day number of the previous payment from the day number of the current payment. The result is the number of days between the previous payment and the current payment.
For example, if the last payment was on 991103 (that is, November 3rd, 1999), and the current payment was on 991202 (that is, December 2nd, 1999), we calculate the day number of the last payment as 99 * 365 (for the year part) + 3 (for the day of the month) + 304 (for the number of days in the year before the first of November), which gives us a day number of 36442. Then we calculate the day number of the current payment as 99 * 365 (for the year part) + 2 (for the day of the month) + 334 (for the number of days in the year before the first of December), or a day number of 36471. Subtracting the first of these numbers from the second, we determine that the number of days between these two payments is 29, which is correct.
Now let's look at the next billing cycle, where the previous payment date will be 991202. Let's suppose that the next payment is on January 2, 2000, which will be represented as 000102. In that case, we calculate the day number of the last payment as 99 * 365 (for the year part) + 2 (for the day of the month) + 334 (for the number of days in the year before the first of December), which gives us a day number of 36471. Then we calculate the day number of the current payment as 0 * 365 (for the year part) + 2 (for the day of the month) + 0 (for the number of days in the year before the first of January), or a day number of 2. Subtracting the first of these numbers from the second, we determine that the number of days between these two payments is... -36469. Somehow that doesn't seem right!
If the credit card company (and their customers) are lucky, the bills this program generates will be obviously idiotic. If they're not so lucky, they may appear to be correct but in fact will be wrong in some unpredictable way. Similar horrors will occur in the inventory control, automobile, and elevator maintenance examples, as well as others too numerous to count.
To return to my main page, click here