Y2K, Millennium Bug, and DOOMSDAY 2000, these are terms that have been used to cover a series of problems related to the ways computers and communication networks have been set up to use, analyze, and process information based on dates. At midnight on December 31, 1999 the world’s computers will flip over to a new century. Many will fail to do so properly. Some will reset their clocks to 1900, others to 1980 or 1983.

The reason for this problem dates back to the early days of commercial computing. Programmers and database administrators attempted to save precious hard drive space by eliminating the century designation from all dates. For example, the date July 5, 1958 would be stored as 050858 in some programs. This can cause problems at the turn of the century. Let’s look at an example of a hypothetical Human Resources program when it compares dates stored in the two-digit year form.

Current Year

1998

2001

Employment Start

1989

1989

Years With Company

98-89 =  9 years

01-89 = -88 years

Further problems may arise because of the fact that computer files and databases store years as two digits. Since many computer applications make date comparisons, or make calculations based on dates, such as may happen in hydrology models, problems could be foreseen when using the systems into the next century. Imagine the problems with overdue payment computations, loan interest calculations, sorting by date, and many other areas.

Date calculations are just one of the problems that will occur at the turn of the century. Many systems were programmed years ago when the millennium seemed a long way off, so “99” and “00” weren’t treated like real dates. Some programmers used these two convenient, easily remembered values as codes for assigning a special status to an invoice or client. For example, a birth year of “99” might indicate that a client is deceased, so he or she should not receive any marketing solicitations. A birth year of “00” might indicate that a customer has declared bankruptcy, so he or she should not be extended any credit.

Another related issue is one of leap year calculation. Here is the proper way to determine whether or not a given year is a leap year:  If the year is divisible by 4, it is a leap year—but like every rule there is an exception. If the year is divisible by 100, it is not a leap year. Unfortunately, there is also an exception to the exception. If the year is also divisible by 400, it is a leap year.  This means that the year 2000, being evenly divisible by 400, is a leap year. Applications that don't apply the third rule above will incorrectly assume that 2000 is not a leap year. Because of this leap year issue, we may not even see all of the Year 2000 problems until February 29, 2000.

Request a free CD-ROM containing the most current upgrades for any of our products. Along with the most current upgrades, tutorials and user documentation will also be included in the CD-ROM.

Click for details