Testing should include a number of critical dates to ensure compliance, so that no problems occur prior to, on, or after January 1, 2000. The algorithms of systems and chips need to be tested for forward and backward processing. Not all systems need to test for all dates listed. Different application domains may have specially significant dates like the fiscal year for business systems. It is up to the program managers to determine which are most likely to impact their systems. The most critical dates that should be considered for testing at this phase include:

November 2, 1997:

Overflow HP/Apollo Domain OS

January 1, 1998:

To ensure that the digits "98" do not trigger a red flag, result in erroneous branching, or otherwise cause a processing error or that "time error" faults occur. Also to ensure that

December 31, 1997

was calculated as the 365th day of 1997. [Found in Y2K patches in mainframes and elsewhere.]

December 31, 1998 to January 1, 1999:

To ensure that the digits "99" do not trigger a red flag, result in erroneous branching, or otherwise cause a processing error or that "time error" faults occur. Also to ensure that December 31, 1998 was calculated as the 365th day of 1998. [Found in Y2K patches in mainframes and elsewhere.]

January 1, 1999:

First day of 1999. Introduction of electronic version of the Euro. First annual plan to look ahead past rollover date.

February 4, 1999:

1st possible airline reservation problems (Max 330-day look-ahead)

March 1999:

Securities Industry Association simulates December 29, 1999 trading.

Fiscal Year 2000 for Business and Industry: Depending on the business, the fiscal year could start on

March 1, 1999, July 1, 1999

or match the government fiscal year of October 1, 1999.

April 1, 1999:

New York state's fiscal year (FY) 2000 starts, and it is the start of the Canadian and Japanese FYs. "99" or "9999" do not trigger a red flag, result in erroneous branching, or otherwise cause a processing error. Some early systems used "9999" as an end-of-file marker which will not work when the data in the file actually includes the value of 9999. Also, many different types of systems have used "9/9/99" as a special date because of the ease of entry. Examples include use as a lock-out code for devices that should not be used until fixed or recalibrated; another common use is as an "indefinite date in the future" for scheduling events like court cases or reviews. When the actual date is unknown or not yet decided, the custom was to enter in "9/9/99" until the real date could be determined.

September 10, 1999:

In systems that have used 9-9-99 as a never expire date, logic allowing deletion of data after a specified date may fail to protect data that should be maintained forever.

September 23, 1999:

99 days to Year 2000.

This is the last fiscal rollover prior to Y2K [for many including the US Government].

October 1, 1999:

First day of fiscal year 2000 [for many including the US Government, and states of Alabama and Michigan]. First quarterly plan to look ahead past rollover date.

November 1999 to April 2000:

Solar activity in solar cycle 23 reaches maximum.

December 1, 1999:

First monthly plan to look ahead past rollover date.

December 31, 1999:

Last day before 2-digit year equals 00. Many systems will not operate correctly as they transition to the next day. Also, sometimes used as "Never Expires" date (IBM tapes are marked 99365--all tapes marked with expiration dates of 99365 or 99366 are not supposed to expire, even when created after 1999).

January 0, 2000:

To ensure this date is NOT processed [some spreadsheets and database applications do have this problem and count January 0 as a day before the 1st].

January 1, 2000:

Key date in any compliance testing. First possible weekend day mistaken for weekday. There is a possibility that the date will be misinterpreted as 1900-01-01.

January 1, 2000, 1200 Hrs (Noon):

Embedded date chip failure has been found.

January 3, 2000:

This may be the first full business day in the year 2000. First possible payday after rollover.

January 4, 2000:

This may be the first business day and first banking day in the Year 2000.

January 6, 2000:

First possible weekday mistaken for weekend day.

January 7, 2000:

First weekly payday.

January 10, 2000:

First 7 or 8 character date in YYYY/M/DD format (2000/1/10 or 2000/01/10).

January 14, 2000:

First semi-monthly payday.

January 17, 2000 (Martin Luther King Day - USA Holiday):

This may be the first Monday holiday in the Year 2000. This holiday is always celebrated on a Monday rather than on a specific date. A day of the week calculation may be required to identify this date as a holiday. A similar situation may exist for holidays in other countries.

January 31, 2000:

First monthly close; first monthly payday. W2s due.

February 28, 2000:

To ensure the leap year is being properly accounted for. Many programmers have incorrectly been taught that the year 2000 is not a leap year -- Year 2000 IS a leap year. Systems should be tested to ensure correct handling of the transition to the 29th day of February 2000.

February 29, 2000::

To ensure the leap year is being properly accounted for. Some systems may transition to the 29th of February 2000 correctly, but may not allow the date to be set to the 29th. This would happen if a system was reinitialized after the transition and should be explicitly tested for.

February 30, 2000:

To ensure that this date is NOT processed [found in some PC applications]

February 31, 2000:

To ensure that this date is NOT processed [found in some PC applications]

March 1, 2000:

To ensure date calculations have taken leap year into account

March 31, 2000:

First quarterly close

April 1, 2000:

Possible false change to Daylight Savings Time (DST) (April 1 was first Sunday in April 1900).

April 2, 2000:

First change to Daylight Savings Time (DST) after rollover (US)

April 3, 2000:

First business day after quarter ends Friday, March 31, 2000

April 14, 2000:

Last business day for U.S.A. 1999 tax transactions

April 15, 2000:

1999 tax filing deadline for U.S.A.

April 17, 2000:

First business day after 2000 tax filing deadline for U.S.A.

September 30, 2000 to October 1, 2000:

This is the first fiscal rollover following Y2K [for many including the US Government].

October 1, 2000:

This is the first 7-digit date with a 2-digit month value. Parsing functions may need to be modified to allow for new date formats.

October 10, 2000:

First 8 character date using a 2-digit month (2000/10/10)

October 28, 2000:

Possible false change back to Standard Time (October 28 was last Sunday in October 1900).

October 29, 2000:

First return to Standard Time after rollover (US). First yearly close.

December 31, 2000:

366th day of the year 2000. This could be a problem for systems that use Short Julian days.

January 1, 2001:

First day in the 21st Century. This is the last leap year related date, testing the first day of January 2001 to ensure it can be set.

February 29, 2001:

To ensure that this date is NOT processed as a leap year

September 9, 2001 (01:46:40 GMT):

A UNIX date when the time_t value goes from 9 to 10 digits. Suspects are timestamps stored in fixed-column tables and internal variables.

After January 1, 2002:

Or any other date past this day, to ensure no processing errors occur in backward calculations and processing of dates in the 1980s and 1990s at this point in time

June 30, 2002:

Last day European national currencies are acceptable.

July 1, 2002:

First day of Euro-only transactions in the European Union (EMU).

February 29, 2004:

To ensure that this date is processed as a leap year

July 17-18, 2004:

GPS Receiver Almanac Rollover due to the use of an 8-bit field for weeks since 22 August 1999 (256 weeks)

January 1, 2037:

Rollover date for NTP systems

January 19, 2038 (GMT):

Overflow of UNIX systems

September 18, 2042:

Overflow of TOD timer on IBM Systems 370 and 390

2072, Exact Date TBD:

Overflow of Milstar Operating System

February 28, 2100:

Last Day of February - NOT a leap year