Y2K Bugs, And Why You Should Still Worry About Them

Introduction

So you thought Y2K was behind us all? Not entirely. I've had some Y2K thoughts bouncing around in my head for a while, and with the new millennium really upon us now, I thought it would be a good time to talk about Y2K bugs and why you still need to be wary of them when writing code. This article talks about Y2K issues that were never addressed during the media blitz of 1999. The ideas can be applied to any programming language.

But first, here is a little Y2K history.

Y2K Prologue

Leading up to the beginning of 2000, the mainstream media was going overboard with stories about "The Y2K Bug" or "The Millennium Bug" or whatever cool name they could think up. Stories were reported about computer companies readying themselves in case something catastrophic occurred at midnight on January 1. More stories, more hype. (Interestingly, I don't recall seeing many stories about people stocking up on supplies, although that did happen -- one local drug store that I visited on December 31 had several empty shelves that had once held bottles of water.)

Of course, the media only caught on to Y2K in 1999, whereas people within the software industry had been dealing with Y2K for years. At Symantec, where I was working at the time, we had had Y2K tests in our testing scripts for 2-3 years, and any product released in 1999 went through a thorough testing to make sure there were no date-related bugs.

I'm sure everyone, not just computer people, was sick of the hype by the time December rolled around. But on December 30, something happened that was real news, not just hype. A system in England that handled credit card transactions went down. The explanation given was that it dealt with dates from the present to two days in the future, and when that date "window" crossed into 2000, the system crashed.

Oh boy. People were really nervous now.

December 31

At Symantec, December 31 wasn't a very busy day, with most folks eager to get to the New Year's vacation. However, there were some members of the press there to do interviews with the Norton AntiVirus product managers (the people who talk to the press and other folks outside of the company).

But for the people in the SARC group, it was a long night. SARC is the group that handles writing virus definitions, which NAV uses to detect viruses. They had to work overnight, in the event that some virus caused massive destruction at midnight and their services were need immediately.

Y2K Post-Mortem

Well, to the best of my knowledge, the world did not end at midnight. And there was no virus breakout that brought big companies' systems down. In fact, that credit card system in England was the only big system crash I heard of. In the non-computer world, the topic of Y2K seemingly vanished on January 2, as the whole thing was viewed as just a bunch of hype and nothing more.

As for Symantec, life went on as usual in 2000. As I mentioned, Y2K was nothing new to us, so nothing really changed. The most important thing to us was waiting for our Q4 1999 bonus checks!

My Y2K Thoughts

The thing that bugged me (no pun intended!) the most about all the media coverage of Y2K was that not one story talked about the real cause of Y2K bugs - laziness, more specifically, laziness of programmers. Programmers were lazy and stored years as two digits instead of four. (And I don't buy the "they were saving space" argument. You can store two digits in a byte using BCD format, and I doubt that, even back in the days of 64K machines, one byte made that much of a difference.) The stories I saw all focused on how computer companies were going back to fix their code so it would work after 1999. Never did they mention that there was nothing inherently broken in computers that meant they wouldn't work in 2000; the programmers who wrote the software were just lazy.

Hey, it's natural to be lazy. Back when I lived less than a mile from work, I sometimes drove to work instead of riding my bicycle. Being lazy can be fun. The trouble is that Y2K bugs arose from laziness with dates. Writing "98" instead of "1998." And since no media stories (that I'm aware of) said that laziness with dates was the cause of Y2K bugs, the general public -- whose sole exposure to Y2K came through those stories -- doesn't understand that laziness is, with regards to dates, very bad.

Now that Y2K has disappeared from the general public's mind, folks are still unaware that being lazy and writing "01" instead of "2001" causes problems. For instance, I saw a news story last week about some bills that Los Angeles county sent out that had a due date of "January xx, 1901." Yes, 1901. The story said that the LA county office "had warned the employees that entering two digits would result in the date showing up at 1901" (paraphrased) but it happened anyway. Why? Laziness.

What Developers Should Do

The good news is that we as developers can do two very easy things to keep year-related problems to a minimum:

1. Don't be lazy.
2. Don't let your users be lazy.

The first part is easy: store years in their entirety, whether it's in an unsigned integer or in text format. Never store a year in anything other than its full value.

The second part is easy too, although at first your users might complain. Never let a user enter a year in anything other than its full value. This means that you should outright reject a year entered as "01", unless you're writing a historical program that deals with the year 1 AD. Why would this make users complain, you ask? They won't like your program telling them they can't be lazy! However, you should absolutely make the user enter the complete year, because doing so avoids other date-related problems.

Enforcing the second rule means that you should not make use of the "windowing" technique, where a two-digit year is assumed to be a 100-year window spanning the 20^th and 21^st centuries. For example, Windows 2000 has a date window setting in the Regional Options control panel:

A program that reads this setting from the operating system could allow a user to enter, say "10", and treat it as 2010.

The problem with this technique is two-fold. First, it's lazy. Letting the user be lazy exposes them to all the two-digit problems I've discussed like the incorrect years in the LA county billing program. While your program may handle two-digit years fine, not every program will, and if the user is allowed to be lazy, they'll eventually run into a program that behaves wrong when given a two-digit year.

Second, because the endpoints of the date window are variable, a lazy user will unknowingly get into trouble when they use a different computer where the window is set differently. If they move to a computer where the window is set to, say 1905-2004, "10" suddenly becomes 1910. If the user isn't paying close attention and doesn't realize they've just entered 1910, problems will ensue.

All of these problems can be avoided by simply requiring years to be entered as four digits.

Conclusion

In the end, users need to be retrained so they only enter four-digit years. It's unfortunate that the media never addressed the laziness factor, since if they had, they could have told everyone how to avoid Y2K-related problems. But since that opportunity was wasted, it's up to us programmers to gently coax users out of their lazy habits.

However, programmers still have to be conscious of their own lazy habits, so that laziness doesn't creep into code and create the potential for Y2K bugs, even in Y2K1.

Further discussion on this topic is welcome - just use the message board at the bottom of this web page.

License

This article has no explicit license attached to it, but may contain usage terms in the article text or the download files themselves. If in doubt, please contact the author via the discussion board below.

A list of licenses authors might use can be found here.