Okay, okay, I told everyone I know that I am not interested in the so-called Y2K problem, and still, I am writing about it. So what gives?

Well, I am still not interested in the problem, but I have become increasingly interested in the phenomenon; the ludicrous amount of hoax and misinformation that is circulated on this subject, not only by laypersons but also by those who ought to know better.

To summarize (as if you haven't seen all this before): they Y2K problem exists because purportedly, programmers of the past (and even the present, on occasions), in order to save precious memory, encoded the year portion of dates as two digits. When the century rolls over to 2000, the year 00 will be interpreted as the year 1900, causing the world to end. Or so the theory goes.

The real proof of the pudding is in the eating, they say, so many would be prophets are likely to fall flat on their faces on January 1, 2000, when their predictions prove to be false. For all I know, this may happen to me also; fortunately, an end of the world, even if incomplete, will in all likelihood bring down the Internet, so no one will be able to read my little essay!

But I doubt it. In fact, I boldly predict that the world will remain largely the same on that fateful date and beyond, or if it ends, it'll be for reasons unrelated to sloppy programming.

Not that sloppy programming doesn't exist, of course. The Y2K problem isn't entirely imaginary. In a big world with over 6 billion inhabitants, quite a number of people will be severely affected by it, I'd not even be surprised at hearing a few cases of death. But...

The terrifying predictions of a Y2K-induced end of civilization are based on a series of false premises. What I find amazing is that these premises are perpetuated by those who really, really ought to know better: experts, real experts, with decades of experience. One could not help but wonder: is it stupidity or are there other reasons behind the scenes that we're not being made aware of?

Let's examine some of these false premises in detail.

Myth 1: Computers Represent Dates in a Decimal Format

This premise is implicitly present behind all Y2K doomsday predictions. After all, if a computer doesn't represent dates using decimal digits, there is no Y2K issue. What's so special about the year 7D0_hex? Or the year 3720_oct? How about 64_hex or 144_oct?

The fact is that while many computers do represent dates using decimal digits, even more do not. Or rather, the question is not the kind of computer in use, but the kind of software, or the programming language in which the software is written. It is far more likely that such a decimal representation is used in languages such as COBOL or dBase, than in C or Pascal.

Myth 2: Dropping the Century Digit is Used to Save Memory

While it's technically true that the fewer the digits, the less memory is used, this is not the main reason why the century digits were dropped. If I really want to save memory, the first thing I do is not to drop the year, but to use a binary representation of the date (and time, if necessary.) I may still drop date digits, but those would no longer be decimal digits, so any rollover would occur on a date other than January 1, 2000.

Consider: if I use a decimal digit representation, dropping the century allows me to use six digits to store the full date: 981211, for instance. This is six characters, or six bytes if encoded using ASCII. Using BCD (binary-coded-decimal) encoding, we're down to three bytes; still, terribly wasteful, as I can demonstrate.

In a recent project, I had to create an efficient format to transmit not only the date, but the time over a slow communication connection. To do so, I encoded the year, month, day, hour, minute, and second values using the following format:

As you can see, even this format is somewhat wasteful; for instance, it allows the month to run from 0-15, whereas we only need month values between 1 and 12. Still... in 32 bits, which is four bytes, we have been able to encode not only the date, but the time, down to the second!

Of course this isn't without a price: we have just created the Y2062 problem. As those evil programmers of the 1960s allegedly did back then, I'm doing the same and say: who cares?

But my point is well demonstrated: an efficient date representation, while it does indeed create a rollover problem, doesn't necessary (indeed, I'd go as far as saying that it isn't likely to) create a Y2K problem.

No, the century part of the date was dropped in most cases for an entirely different reason: lazy users and/or small screens. This aspect of the problem is not new; long before computers became a permanent addition to our lives, many printed forms already contained the preprinted century (sometimes even the decade) part of the year.

Needless to say, this doesn't change the seriousness of the problem by itself: if the century is missing, you got trouble regardless of the reason why the century was not included in the first place.

Myth 3: Embedded Systems will Malfunction Everywhere

Oh yes, embedded systems. Everything these days, from your telephone to a variable intensity lamp, from your car to your children's toys, contains one or more computer chips. These will all die on January 1, 2000, or so the pundits say.

But the pundits are wrong. To begin with, the vast majority of embedded systems do not care what date it is. They simply do not have a real-time clock, or RTC. This is true about your child's toy, just as it is true about your living room light or electronic bathroom scale.

Of course there are many devices out there that do have real time clocks. Why else would you have to set your VCR every time the power goes out? Or how about your clock radio? Your TV set that can display the date and time? Or, to go on to something more serious, your car engine that knows when it is due in for maintenance, and lights up an idiot light on your instrument panel to warn you?

Well, yes. But consider the following:

• Embedded systems are the least likely candidates for a programming error that involves a decimal representation of the date. These systems are programmed using machine language, or, in the case of newer systems, a low-level programming language, and data representation is typically binary.
• Most embedded systems that have an RTC nevertheless still don't care about the date; for instance, one of my VCRs knows what time it is, what day of the week it is, but doesn't care what date it is;
• In embedded systems that do know the date, it is unlikely that the date in any way relates to the system's critical function; i.e., the date may be used to warn about maintenance due or timestamp reports, but is unlikely to be used in any real-time sampling or control function.

Myth 4: All Instances of the Y2K Problem are Critical

Nothing can be further from the truth. The vast majority of the Y2K problems that will be encountered will be cosmetic in nature. Reports will be printed with the wrong headers, systems will issue spurious warnings, and such.

Of course there will be critical problems. Systems will erase large amounts of data when these are deemed obsolete, 99 years old, due to a Y2K-related programming error. Real-time systems will malfunction when they assume that the last few data bits represent not one second, but -3155673599 seconds of measurement. Clerks will be unable to enter dates via two-digit input fields. Faulty accounting software will calculate -99 years of interest on unpaid accounts. And so on. But this is not really something special: such problems are occurring all the time! The only thing that makes the Y2K problem special is that a large number of such faults are expected to occur at the same time, overwhelming our technological society with their compounded impact. Or...

Myth 5: All So-Called Y2K Bugs will Occur on January 1, 2000

Well, no. Some "Y2K" bugs will occur days, weeks, months, even years later. For instance, when the first quarterly report is generated that involves items dated in the new century.

More importantly, some so-called Y2K problems will occur at seemingly arbitrary dates. That is because programmers do not use a decimal representation for dates! For instance, many computer programs will fail miserably at 03:14:08 AM on January 19, 2038. Why such an arbitrary date? No, not arbitrary at all... it is exactly 2³¹ seconds after midnight, January 1, 1970. And it so happens that on all computers running UNIX, and on many other computers, the system time is measured using a 32-bit quantity, as the number of seconds elapsed since 1970. Now many programs treat this 32-bit quantity as a signed number, leaving only 31 bits for the data... which takes us to 2038. Since UNIX and its derivatives are used in far more embedded systems than the business oriented programming languages prone to the decimal Y2K problem, perhaps those emergency supplies are best collected in 2038 instead of next year...

So yes, there is definitely a Ynnnn problem, but nnnn isn't necessarily the number 2000. But if not all "Y2K" bugs occur at the same time, and computer bugs occur all the time, why are we all so scared?

But no, I do not advocate complacency. If anything, the Y2K problem provides a good opportunity to review systems that were on the verge of falling into, or have already fallen into, serious disrepair. Moreover, when it comes to critical systems on which human life depends, no amount of precaution is too much, especially when we're warned of a potential problem beforehand.

But I do believe that the wisest way to prepare is not by going into panic mode, hiring thousands of programmers who comb through every piece of source code in the archives. Run tests, if possible, realistic tests that exercise your systems configured for various system dates beyond 2000. But don't be surprised if your tests uncover nothing, or only trivial issues; after all, there is yet another premise that we have not discussed. Programmers do make mistakes (oh, how many mistakes!) but most of them aren't complete idiots; chances are that even if all the above arguments fail in your case and your systems are particularly prone to Y2K failures, a kind soul has already thought of it in the past and wrote proper code.

In the meantime, make sure you stop worrying about the Y2K disaster long enough to plan for the party of the century...

December 11, 1998

Needless to say, the world survived January 1, 2000, without disaster. By some estimates, up to 500 billion dollars were spent world-wide fighting the Y2K ghost. This amount exceeds many estimates on the cost of not only flying a man to Mars, but the cost of establishing a semipermanent human presence on the Red Planet. Saddest of all is that the loudest advocates of Y2K spending now use the fact that no disaster occurred to justify their stand on this issue: had we not spent on this money, they say, disaster would surely have struck! When asked why no disaster hit those countries, including a few highly industrialized nations, where Y2K spending was kept at a much lower level than in North America, they remain wisely silent...