There are many people out there who are aware of impending problems with the millenium change ("year-2000 problem" or "Y2K problem") but whose concept of just what it means is somewhat distorted.

For those who may not have a clear understanding of the problem, here's a brief explanation. Back in the days when computer programming was young (last year, and the twenty or so years before that one...), software designers decided to store dates (or at least years) without the century. That, in a nutshell, is the core of entire problem. Without the century, it's a problem determining whether "2/3/00" means "February 3, 1900" or "February 3, 2000".

In many applications, dates are stored in YYMMDD format, which means that the above date is stored as "000203". July 4th of the year 1998 would be stored as "980704". This format made it easy to compare dates since the more recent date was always numerically greater than the older date - until the year 2000, when this method will no longer work. There are several other formats used to store dates, but the essence of the problem is the same for all of them: lack of a century indicator.

So why was this was done so wantonly when the programs and databases were originally designed? Many in the software field would suggest that it was to save two bytes for every date that is stored. Hovever, the answer I received as a neophyte programmer 25 years ago when I asked the design analyst that question was: "I'll be retired by the time this is an issue..."

The effect of the problem can be easily demonstrated. Suppose we have a program that determines how old you are (in years) based on your birthyear. All it has to do is subtract your birthyear from the current year. So, if you were born in 1960, the calculation will be 1998 minus 1960, or 38. In the year 2000, the calculation works just as well: 2000 minus 1960 equals 40. But what if we didn't have the century stored with our dates? It's easy to see that 98 minus 60 still works, but 00 minus 60 doesn't work!

The only applications that will be affected are those which rely on date processing, and the largest proportion of the money being spent for programming and database corrections is in the fields of finance, insurance, and government administration. It's a serious problem not because of its complexity, but because of its insideous presence in so much business software. But let me allay some fears and concerns here: while things like billing and license renewals and insurance premium calculations may be affected, it's not likely that any catastrophic events will take place after the stroke of midnight on December 31, 1999. Here's a list of some of the concerns that people have expressed (none of which are going to happen):

• Airplanes will fall from the sky because their software will crash when it tries to determine the date after flying over the International Date Line.
• A nuclear war will begin because the automatic timing mechanisims in fail-safe systems will go awry.
• People will be stranded during blizzards without light and heat because utilities will assume they haven't paid their bills in 99 years.
• The stock market will crash because all trades will go unsettled.
• No one receive Social Security checks because no one will be older than 62 as far as the government's computers are concerned.

There are dozens more examples of such notions, and I'm sure the list will grow for the next 15 and 1/2 months. I can assure you that in spite of the massive effort that's been going on to address this problem, we will meet with software bugs and failures as the millenium changes. However, it will not be armageddon. Like they do now, our lives will continue with a love-hate dependence on computers, and these ubiquitous machines will continue to make life easy as well as annoying.

Thanks for stopping by. I update this column each month or so to discuss various issues ranging from software development to the meaning of life. Please check back soon.