MITRE - Y2K - Critical Date Transitions

The following Y2K material has been kept available by MITRE for historical purposes only and has not been updated unless noted.

Critical Date Transitions

The Basic Set of Dates
The dates discussed here constitute the minimum set of critical dates that must be examined to determine if a system or product is Y2K compliant.

December 31, 1999 to January 1, 2000: This is the basic Y2K transition (occasionally called the "millennium transition") and the one that is most likely to cause a product to fail catastrophically.

February 28, 2000 to February 29, 2000: The year 2000 is also a leap year, although some systems might not know that. This transition must be examined to determine that the product performs the leap year calculation correctly.

February 29, 2000 to March 1, 2000: At one time, there was a rumor circulating in Y2K circles that the year 2000 is a "double leap year", that is, that is would also have a February 30 in addition to the 29th. Not true, and in any event, this transition should be checked to complete the leap year verification.

December 30, 2000 to January 1, 2001: This is the same as December 31 if there is a bad leap year calculation.

December 31, 2000 to January 1, 2001: This is the last of the minimum set of Year 2000 transitions and takes the system completely into the new century. It also completes the leap year evaluation by establishing that the product "knows" that the year 2000 has 366 days.

Other Critical Dates
Some systems may have vulnerabilities to other date transitions than those listed above. Financial systems, for example, are very liable to be sensitive to the rollover of fiscal years in addition to calendar years. Fourty-four US states (along with many private companies, and probably a few countries around the world) operate on a July 1 fiscal year. New York State's 1999-2000 fiscal year and Japan's 1999-2000 federal fiscal year begin April 1, 1999. For financial systems that follow the government fiscal year, the evaluators should consider the following:

September 30, 1999 to October 1, 1999: This is the last fiscal rollover prior to Y2K.

September 30, 2000 to October 1, 2000: This is the first fiscal rollover following Y2K.

For systems following different fiscal years, the selected dates should be adjusted accordingly.

Magical Dates Using Reserved Numbers
There are also certain magical dates that products may be sensitive to because the developers used some fields in the date as flags to indicate special situations or circumstances to the software. Any time in the year 1999 could cause problems like this if the software developer used a year value of 99 to mean something special such as: "never purge." The date 9/9/99 might be critical if the software treats a date containing 9s as a special flag. The number of possible "magical" dates is limitless and the evaluators will need to be creative and thorough in seeking them out and adding them to the list of test scenarios. It is up to the evaluator, developer, and test staff to determine what that is for each product. For a list of dates to test around including "magic dates," please see our Comprehensive List of Potential Y2K Problem Dates.

Date Horizons
It may not be sufficient to simply observe the product across each of the identified critical dates. This is because of "date horizons" that the product may have. Date horizons determine the product's time interval of interest.

The product's "leading date horizon" determines its view into the future, and the "trailing date horizon" determines its view into the past. A forecasting system that predicts staffing requirements for the next six months has a leading date horizon of six months. Similarly, a program that calculates productivity over the past month has a trailing date horizon of one month. Some systems have only a single date horizon, either leading or trailing, and some have both. The figure above illustrates the concept of date horizons.

For systems with date horizons, it will be necessary to execute test scenarios that cause the relevant horizons to cross the selected critical dates, in addition to causing "time now" to cross each date. If the date horizons are so long that the test setup cannot be tied up to permit the continuous flow of leading date horizon, time now, and trailing date horizon to cross the critical date, the scenarios need to be broken into pieces. In such cases, care must be taken to ensure that the test data from the leading date horizon, through time now, through trailing date horizon, is consistent so that a true picture of product operation can be obtained.

A Word of Caution
Testers and evaluators must be careful when executing test scenarios that involve advanced dates. Simply setting the system clock forward may cause unanticipated effects. For example, setting the date forward to December 31, 1999, which is currently two-plus years in the future could cause software licenses to expire, or passwords, or user accounts, or files, etc., to fail.

The rule for Y2K evalualtion and testing is: Test only on an isolated system that has been thorougly backed up.

Test & Eval	Testing Basics	Renovation Strategies	Product Evaluation	Critical Dates
Resource Allocation	Interface Management	Interface Agreements	Interface Status	Confidence Assessment