January 1, 2000 is just another bad date

Jan. 1, 2000 is a notorious date, but it is not the only dangerous date for software systems. The Year 2000 problem is just the tip of an iceberg of date sensitive trouble on the horizon. This obstacle cannot be overcome with a simple high jump over the Jan. 1, 2000 barrier. As track and field events go, it will be more like running over a series of hurdles at high speed. And the starting gun for that event is set to go off sooner than you might think.

Software applications use two basic approaches for tracking dates: A standard format for ordering the digits representing the year, month and day (eg: yyyy/mm/dd) and a method of counting the elapsed time from an arbitrary starting point (eg: 6789 days after Jan. 1, 1980). Beginning in 1999 both date tracking approaches will be affected by discrepancies.

One of the first bad dates is Aug. 21, 1999. On that date the Global Positioning System (GPS) satellite date tracking approach, which is based on a 1,024 week cycle starting from Jan. 5, 1980, will reset itself to zero. The GPS system itself is expected to function properly, however, third-party equipment and software applications which rely on GPS data may not work correctly following the adjustment.

The next ominous date is Sept. 9, 1999. Software applications need a way to indicate the end of a file so that it can be closed safely. One technique uses the number 9999 as a file termination code. If September 9,1999 is represented as 9999 it may be misinterpreted by a program and cause miscalculations. Of course, on Jan. 1, 2000, the use of only two digits to represent the year in a date creates an ambiguity which can cause miscalculations.

Another bad date is Feb. 29, 2000. A leap year is determined by applying three rules: (a) the year is evenly divisible by four, (b) unless it is also evenly divisible by 100, in which case it is not a leap year (c) unless it is also evenly divisible by 400, in which case it is a leap year. The year 2000 would not normally be a leap year but every 400 years a leap century occurs. Accordingly, there will be a Feb. 29, 2000. Missing a leap year date can cause applications to shut down or double post calculations.

Compatibility problems with dates in data files can be caused by the different formats used in the USA (month/day/year), numerical systems (year/month/day) and Europe (day/month/year). ISO has adopted a standard based on eight digits in a yyyy/mm/dd format. However that is inadequate for many purposes.

Another suggestion is a nine-digit standard with eight digits for the date and one digit as a key to indicate the format used. This innovative, flexible approach can accommodate numerous commercial, scientific and cultural date formats with precision. For further information see Bad Days For Software, Capers Jones, IEEE Spectrum Sept. 1998 p.47.

Accordingly, when requesting a warranty from a software supplier, remember that Jan. 1, 2000 is only one of a whole bunch of bad dates. Request confirmation that the functional and performance characteristics of the software will not be adversely affected by any dates. Consider the response you get to that request carefully before you make a software acquisition decision. /

David M. Robinson, LLB, is executive director of The TechKnowledgey Group, advisers on negotiating and document ing complex IT transactions. Tel: (8913-3833; email: into@tkygmup.com.

Copyright Plesman Publications Ltd. Jan 1999
Provided by ProQuest Information and Learning Company. All rights Reserved