By John McLaggan

Dear Ladies and Gentlemen,

It is now the fourth day of the year 2000. What does this mean? It means that the first working day of the New Year is behind us. We all expected things to go wrong. But in fact it was only this expectation that went wrong – everything else worked and went right!

Who is to blame for this expectation unexpectedly going wrong? It is people like YOU who are to blame, dear Contractors! Some of you were directly involved in making sure that things would go as they should after the midnight of December 31st, 1999. Those of you who were not directly involved were, along with the rest of the outside world, certainly intimately aware of the issues that were at hand.

Let us have a look at these issues in detail.

1. Many a computer, when confronted with a year 00, would put it behind year 99, then behind year 98, and so on until year 01, so that 00 was in fact year 1900.
Looking back, I do not recall a single company internal notice advising that date fields in databases and program working storage areas should represent the year with 4 digits. So it was up to far-sighted programmers and database administrators to adopt of their own accord the 4-digit year in new applications. Existing applications had to await conversion until the launching of some special company-wide project, the name of which generally came to be known as Y2K. This was because, as every one in the computer business knows, you do not change a winning team.
Very many organisations left their Y2K projects until almost the last minute and discovered that they were undermanned, so that external staff had to be recruited, with correspondingly extra costs. Some managers of computer departments were extremely reluctant to recognise the urgency of the issue. My boss simply said as far back as 1995 that for him it would be no problem, that he would go into voluntary retirement by 1999, at age 50. I guess he could afford to, as a vice-director.

2. Some programmers like to imagine that their „Works of Programming Art“ are going to last into eternity and so programmed accordingly. They made leap years out of every year that left no remainder when divided by 4. They also accounted for the rule that said that a year which left no remainder when divided by 100 was, in contrary to the dividing-by-4 rule, not a leap year. But unfortunately they did not know about a third rule which, contrary again to rule 2, said that a year which left no remainder when divided by 1000 was indeed a leap year. In effect, it would have been better if those types of programmer had been more realistic and seen that their „Works of Art“ have a relatively short life expectation, and had not considered the hundred year rule at all.

3. Funny dates are often the target of clever and cunning programmers who use them to get out of uncomfortable situations which would otherwise make their programs not work. For instance, in the personal dossier at the local council the date of birth of a person is a field which has to be filled in, because everyone was born at some definite time. What if the council user has not been able to get this information ? The program will not let the data be stored without the birth date. Or if the field were left blank, some batch program would crash.
The solution is to use a pseudo-date : a date which theoretically could be a real date, but that anyone interpreting the data knows full well is a bogus one.
One such date with many such uses is 11.11.11, and another was none other than 9.9.99! Clearly, this was not strictly a millennium bug, but the issue was treated as part and parcel of the millennium problems because of its proximity to the year end of 1999 deadline.

Congratulations, dear Contractors, you have done it again, your combined effort has helped save the world from declining into an unfathomable abyss of doom. The world is saved, and history repeats itself, for was it not exactly 2000 ye

Return to News Archive