Year 2000 (Y2K) Information

Are your embedded systems and software  or Y2K troubled?

To help you find out, click on the following buttons:

	Key Y2K Dates	Time since Year 2000 Days : Hrs : Min : Sec
Date (Y/M/D)	Remark(s)
1900/01/01	For programs that support historical data, verify that this was a Monday.
1900/02/28	Identifies hidden leap year processing problems. Ensure 1900/02/29, 1900/02/30, and 1900/02/31 are not recognized as valid dates (not leap year).
1971/12/31	Contingency for 1999/12/31, and annual roll-over to year 1972 (contingency for annual roll-over to year 2000).
1972/01/01	Contingency for 1999/01/01.
1972/02/28	Contingency for 1999/02/28, leap year test (contingency for year 2000 leap year test).
1972/02/29	Contingency for 1999/02/29.
1972/03/01	Contingency for 1999/03/01.
1989/09/19	For DOS programs that maintain the date as days since 1900/01/01, programmers who failed to specify "unsigned" 16-bit integers had their dates suddenly change to early in the 19th century.
1997/11/02	Overflow HP/Apollo Domain OS.
1997/12/31	365th day of 1997, and roll-over to year 1998/01/01. Must operate correctly; has special "flag" meaning in some environments, i.e., retention and expiration of resources for some operating systems.
1998/01/01	Ensure that the digits "98" do not trigger a red flag, other program subroutine(s) resulting in erroneous branching, or otherwise cause a processing error, or that "time error" faults occur.
1998/12/31	This date has special meaning related to the retention and expiration of resources for some operating systems.
1999/01/01	Ensure that the digits "99" do not trigger a red flag, other program subroutine(s) resulting in erroneous branching, or otherwise cause a processing error, or that "time error" faults occur.
1999/02/05	First possible airline reservation problems (maximum 330-day look-ahead).
1999/03/01	Base line for calculating day of week (DOW).
1999/04/09	Julian date 9999 (99th day of year). Some applications may use "9999" for special purposes, i.e., default end-of-file indication, dataset retention, delete or not.
1999/04/20	255 days to year 2000 could cause a very rare problem related to look-ahead logic and 28 = 256.
1999/08/19	Sometime after 22:00 Universal Coordinated Time (UTC) or GMT, the almanac updates start uploading to the GPS satellites, to prepare for the 1999/8/22 (or second) GPS epoch.  GPS receivers and reference stations may experience malfunctions when trying to use the new almanacs, if not compliant with GPS second epoch.
1999/08/22 and approximately every 20 years thereafter	The atomic clocks inside Global Positioning System (GPS) satellites will be reset at about midnight,  actually Aug. 21, 1999 at 23:59:47 GMT. The "end of week" causes Week Number Roll-Over" (WNRO) to roll-over to week 0000 after week 1,023 because GPS was designed to operate for only 1,024 weeks (now first epoch).  GPS receivers and reference stations must be updated in order to continue receiving signals (second and consecutive epochs).  Unremediated GPS receivers will reset to 1980/1/5, miscalculate 1999/8/22 as 1980/1/6, 1999/8/23 as 1980/1/7, and so on.
1999/09/01	Computers and embedded systems with three-digit date blocks will hit "999" for the 9th month of the 99th year.
1999/09/09	Gregorian date 9999. Some applications may use "9999" for special purposes, i.e., dataset retention, delete or not, default end-of-data or end-of-file indication, expiration of resources, file purge (in older code), null set, etc.
1999/09/23	99 days to year 2000.
1999/11/??	Leonids meteorite showers may impact some satellites (can not simulate for testing purposes) - date to be determined.
1999/12/31	Last day of year 1999 (not of 20th century), and annual roll-over to year 2000. Must operate correctly, and has special "flag" meaning in some environments.
	365th day of 1999. 99365 may be used to indicate "never expires" date, i.e., IBM tapes are marked 99365.
2000/01/01	Year rollover may cause system anomalies and possible shutdowns.  First day of year 2000 will be a Saturday (not 21st century yet). Ensure that 2000/1/0 is NOT processed (some applications do have this problem and count January 0 as the day before January 1).
	Embedded date chip failure at 12:00 noon.
	For GPS systems using two digits for the year, 2000 becomes "00".  This could be interpreted as 1900 for calculations, or could be treated as an invalid date.
	Inmasat has identified the following erroneous dates (Y/M/D) when systems roll forward from 31 December 1999: 0/1/0 (single 0 in year field preceeded by spaces), 00/1/1 (with 00 meaning 1900), 1936/2/16, 1970/1/1, 1980/1/1, 0200/1/1,19100/01/01 (transition from '99 to '100), and possibly a negative number.
2000/01/01 and beyond	Crouch-Echlin effect (time dilution problem) could cause the PC clock to intermitently display the incorrect date when booting after the year 2000.
2000/01/03	First full business/work day of year 2000.
2000/01/06	First possible weekday mistaken for weekend day.
2000/01/07	First weekly payday.
2000/01/10	First date to require a 7 digit date field.
2000/01/14	First semi-monthly payday.
2000/01/31	End of 1st month of year 2000 processing.
2000/02/28	1st leap year test. Ensure that 2000/2/30 and 2000/2/31 are NOT processed (found in some PC applications). 2000/2/29 will be a Tuesday.
2000/02/29
2000/03/01
2000/03/01	Base line for calculating day of week (DOW).
2000/04/01	Begins year 2000's 2nd quarter.
	Possible false change to Daylight Savings Time (DST) in USA. April 1 was first Sunday in April 1900.
2000/04/02	First change to Daylight Savings Time (DST) after rollover (USA).
2000/07/01	Begins year 2000's 3rd quarter.
2000/10/01	Begins year 2000's 4th quarter.
2000/10/10	First date to require date field using the maximum length (8 digit).
2000/10/28	Possible false change back to Standard Time (October 28 was last Sunday in October 1900).
2000/10/29	First return to Standard Time after roll-over (USA).
2000/12/30	May be a problem for systems that do not recognize 2000 as leap year.
2000/12/31	End of year 2000.  The system should recognize day 366 of year.  May cause a problem for systems that use short Julian dates.
2001/01/01	Begins first year of 21st century. Will be a Monday.
2001/02/28	Non-leap year test. Ensure that 2001/2/29 through 2001/2/31 are NOT processed.
2001/03/01
2001/09/08	999,999,999 on UNIX systems (could be reduced to 99 and trigger errors). Time_t value goes from 9 to 10 digits.
2001/09/09	Look for time stamps stored in fixed-column tables and internal variables.
2001/12/31	End of 1st year of new millenium with 365 days.
2002/01/01	Ensure no processing errors occur in backward calculations and processing of dates in the 1980s and 1900s at this point in time.
2002/02/28	Non-leap year test. Ensure that 2002/2/29 through 2002/2/31 are NOT processed.
2002/03/01
2003/02/28	Non-leap year test. Ensure that 2003/2/29 through 2003/2/31 are NOT processed.
2003/03/01
2004/02/28	2nd leap year test. Ensure that 2004/2/30 and 2004/2/31 are NOT processed.
2004/02/29
2004/03/01
2010/01/01	Overflow of ANSI C Library (alleged to be a valid Y2K problem date).
2029	Two-digit year limit for Microsoft Access '97 and Excel '97, as well as Lotus Approach '97 (in all cases, their four-digit year limit is 9999).
2034/09/30	Overflow of UNIX time function (2038/1/19?).
2036/01/01	MS-DOS v6.22 operating range of 1980/1/4 - 2035/12/31 exceeded (PC BIOS dependent).
	Windows 95 operating range of 1980/1/1 - 2035/12/31 exceeded (PC BIOS dependent).
2037/01/01	Windows NT Server and WorkStation operating range of 1996/1/1 - 2036/12/31 exceeded.
	Rollover date for Network Time Protocol (NTP) systems.
2038/01/19	231 seconds after start date of 1970/1/1 causes C, C++, and UNIX systems to roll-over (32 bit overflow).
	Overflow of IBM system 360.
2040/02/06	Older Apple Macintosh computers may revert to 1904/1/1 loosing 232 seconds.
2042/09/18	Overflow of IBM system 360 (2038/1/19?).
2044/01/01	Poorly written DOS code may have problems with date if bit extraction is done improperly (7 bits allocated to year field).
2049	Two-digit year limit for Lotus 1-2-3 '97 (four-digit year limit is 2099).
2049/01/01	May detect residual date windowing. Verify proper operation.
2050	Two-digit year limit for Corel Quatro Pro 8 (four-digit limit is 3199).
	Two-digit year limit for Corel Paradox 8 (four-digit limit is 9999).
2050/01/01	May detect residual date windowing. Verify proper operation.
2051/01/01	May detect residual date windowing. Verify proper operation.
2059/01/01	May detect residual date windowing. Verify proper operation.
2060/01/01	May detect residual date windowing. Verify proper operation.
2061/01/01	May detect residual date windowing. Verify proper operation.
2069/01/01	May detect residual date windowing. Verify proper operation.
2070/01/01	May detect residual date windowing. Verify proper operation.
2071/01/01	May detect residual date windowing. Verify proper operation.
2072 (TBD)	Overflow of Milstar Operating System.
2079/06/07	16 bit counters will roll over for DOS programs that maintain the date as days since 1900/1/1.
2100/02/28	Last day of February (not a leap year).
2108/01/01	Roll-over for DOS file system time with date in a packed integer field.

Go to "Contents" above

	Y2K NOTES
No.	Remarks
1	"Millennium Bug" is an incorrect, misleading name for a fault. Many people have reasons to believe the 3rd millennium really starts on 2001/1/1 instead of 2000/1/1. Besides, Y2K is not a bug, much less a virus. Unfortunately, Y2K is an unpleasant feature of many embedded systems and software!
2	To become Y2K compliant, start by using 4 digits for all year representations.  Do not forget to change the year representation format in regional settings  to "yyyy".  For MS Windows 95, 98, and NT, start -> settings -> control panel -> regional settings -> date tab -> yyyy/mm/dd (ANSI date format) or mm/dd/yyyy.
3	A leap year occurs in every year that is evenly divisible by four, with the following variations: years that end in '00' (such as 1900) are not leap years, except for years divisible by 400 (such as 2000, 1600, or 2400) are leap years. Therefore, the year 2000 is a leap year, but 1900 and 2100 are not.
4	Dates related to end / beginning of fiscal years are generally not considered in this list. Depending on your business, the fiscal year may start on January 1, March 1, July 1, or October 1.
5	Dates prior to 1980 may be considered "preposterous" or out-of-range for your system, so using 1972 as a contingency is not always possible.
6	Please contact CEscoffery (via ACP intranet) or cescoffery.ee76@gtalumni.org (via internet) should you find any mistake and/or other relevant dates or links not listed above. If possible, furnish Internet URL of source data.
7	Contact me for assistance on Contingency/Renovation Plans, Critical Suppliers, Y2K Compliance Certification (for embedded systems and software), validation, and verification.
8	Programs that support the reading of historical data must correctly read previous versions of data that may have included years written in two-digits in date fields
9	Many key dates above may not be applicable to your applications, and some far future dates are presented here for reference (too far away for you to worry about).
10	Not many people live to be 100 years old, but many events happened over 100 years ago.  Your software may have the "Y100 bug" i.e., you get "00" or "10" when the age 100 is entered in a data base.
11	Global Positioning System (GPS) has a problem of its own that is related to WNRO, not to Y2K, but is included here for convenience. GPS almanacs are data tables containing information to predict which satellites are in view at an estimated location and time. Also, GPS time is independent from UTC time.
12	Thanks for your comments. These are considered and cause frequent changes to this web page. Come back soon...