<!-- Add the rest of your HTML here -->
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.
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
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.
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.
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:
- Don't be lazy.
- 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 20th and 21st 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.
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
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.