I do not give forecasts of general and social consequences; do not ask.
2007-01-21 : Many dead links are now underlined.
Many systems, both ancient and modern, store and/or compare the year number as two digits, and will therefore run into difficulties by the year 2000 - or, rather, whenever any date used computationally begins to exceed 1999. For year-ahead planning, this means on 1999-01-01 (cf. the Jo Anne Effect, where data is collected in financial-year batches, and failures begin at the start of the financial year which ends in 2000); for 15-month lookahead, on 1998-10-01; for employees' birth-dates, not until the mid twenty-teens.
This applies both in visible computers large and small, and in embedded systems.
PC date rollover failure is but a minor part of the problem, although it does concern a large number of people. Errors of date logic in systems are far more important, as those responsible will know already.
I have read "The National Bureau of Standards FIPS PUB#4, November 1, 1968 which required all data exchanged between US Federal government agencies to have 6 digit dates".
For more, see my Date/Time page and Critical and Significant Dates; and Y2k Introduction, Mini-FAQ, Time Dilation, Testing, References, and the other links herein.
As issued, Windows File Manager (<win98) has a mild cosmetic problem from 2000; default file date display counts the years after 98, 99 as :0, :1 .. :9, ;0 .. , <0 .. , ... , A0 .., ... ; the century, if present, is 19. These Microsoft files should fix the flaw : run in an empty directory or floppy :- Windows 3.x, Windows for Workgroups 3.11, Windows 95. It is reported that UNIX can do likewise.
NOTE 2005-02-07 :-
220-Microsoft FTP Service
We will be turning off ftp.microsoft.com on May 1st, 2005.
Please use the Download Center: http://www.microsoft.com/downloads
The updated WfWg version, set to ISO 8601 8-digit date format, reduces displayed dates after 2079 by 100 years, and so does Windows 98 File Manager - and "My Computer", while correct on a file dated 2100-01-01, mishandles a file dated 2107-01-01 and also a file dated 1980-01-01.
The BATC on ISO 8601.
MS-DOS (≤6.20 tested) DIR shows a two-digit year for file dates (range 1980-2107), and so is ambiguous if dates can exceed 2079; dates after 2099 are shown as 99!
The well-known non-MS DOS program LIST shows the ":0" effect for files in 2000-2059, but from 2060 displays as for (Year-160) (V6.2a tested).
Gary L. Smith :- " ... created ... file ... year ... date ... 2107. The Windows NT functions and applications I've checked so far all display the year as 07 or 2107, depending on whether they use 2 or 4-digit years."
HUNTTEST.ZIP contains a set of zero-length test files (use XCOPY to copy) with various dates, 1980-00-00 to 2107; my HUNT displays all 232 conceivable valid & invalid DOS file dates correctly. DOS DIR, however, may report such wrongly (e.g. Win98 DOS box).
Similar problems may of course occur with other software and on other types of computer.
It is recommended that Windows be set to use YYYY-MM-DD 24-hr HH:MM:SS whenever possible, on general grounds. This I use now; it seems correct. However, some badly-written software may be troubled by it.
Ian Galpin had "Instructions for Various Computers to use the ISO 8601 Year-Month-Day format".
It is reported that if Windows is set to YYYY and a YY date is entered in a spreadsheet, the date may not be recognised as such - and "/" separators treated as divisions. Also, the correct separator for the spreadsheet setting must be used.
One can also try foreign settings for DOS with COUNTRY in CONFIG.SYS; Chris Anderson's mini-FAQ has recommended 002. However, if one can judge by a DOS 5.0 manual, for most users COUNTRY=046 would benefit the time and date equally and use better codepages, and those using 036, 038, 042, 048 already have the best time and date, and would perhaps do better to keep their Slavic page 852. See a sufficiently full (early) DOS manual, or "Dos-Prompt>HELP COUNTRY Notes"; and test.
Be aware that this setting affects the "thousands" spacing of numbers. UK/US/similar users will be accustomed to 12345678.9 and also to 12,345,678.9 in print. International standards are taken to require 12 345 678,9 but the decimal comma is not congenial to Anglos and programmers and the spaces are visually difficult in a fixed-width font; indeed, the spaces should be thin-spaces.
Tests seem to show that I can set COUNTRY=061, but that the information about it in the DOS 5 manual, omitted in the DOS 6 manual, is actually wrong for my DOS 6.20 - the date/time order given is correct, but the time is 12-hr.
I have tested DOS 6.20 with Countries 002 = Canadian-French, 046 = Sweden, and 061 = International English. The formats for file size in DIR, date, time :-
002 1 498 98-06-11 18:35:03,22 046 1 498 98-06-11 18.54.04,27 061 1,498 11-06-98 6:41:44.12p
For me : in 002, the time-comma is rarely seen but the number-space is unacceptable; in 061 the 12-hr time is unacceptable, the date-order is inferior, and the number-comma is just tolerable. In earlier DOS there was no thousands-separator, which was better (except for vast numbers).
So it seems to depend on which combination of properties, none ideal, you prefer.
Ian Galpin (see link above) has recommended COUNTRY=086.
Other software can be much more seriously affected.
In a system with date errors, large amounts of data may be prematurely purged; be careful when testing.
MS-DOS MSBACKUP - see the Microsoft Web site for details.
Someone has written (In a context assuming the DIR & BACKUP errors are known), in answer to "Does anyone know what the how DOS stands relative to Y2K. Is it compatible? If so, what version(s)?", "I have tested MS DOS 3.3, 4.0, 5.0, 6.0, 6.2 and 7 - No problems.".
Also, CHKDSK appears to use only 4 bits for (Year-1980) when creating FILE####.CHK files from lost chains.
Link Edit (Make) may fail, because of date comparison errors; also any "Load Latest Version" function.
I have read that Microsoft had a Y2K patch for Win95 (it replaces COMMAND.COM); and that they had a Y2k Win95 web page, in year2k/.
Some software still gives two-digit years on articles. I understand that this probably will be acceptable to most systems, but not necessarily to all. RFC 822 refers. It seems wise to apply "Be conservative in what you send and liberal in what you receive" (RFC1855/FYI28). Some software may go from 99 to 100, or even to 10, instead of 00.
Although not an RFC, Son-of-RFC1036 (Henry Spencer, 2 June 1994 - expires 15 July 1994) (now RFC1849) Sec 5.1 is interesting here, even if some don't like it (I have no seemingly-relevant RFCs; maybe someone with a full set might look) :-
The year SHOULD be given as four digits, and posting agents SHOULD enforce this; however, relayers MUST accept the two- digit form, and MUST interpret it as having the implicit prefix "19". NOTE: Two-digit year numbers can, should, and must be phased out by 1999.
But Richard Clayton has written (1998-07-08) :-
Where NNTP (or article handling prior to injection to NNTP) is date dependent it is by common consensus going to be deemed to use a windowing system : i.e. it will be treating 99 as 1999 and 00 as being 2000 for quite a while yet.
so all should be well.
I have seen a document saying that Net dates are to be windowed into 1950..2049.
However, I suggest that a programmer who has omitted the simple precaution of using 4-digit years is quite likely not to have arranged to handle two-digit ones correctly.
Ensure that the TZ environment variable is correctly set, if it may be used.
Re IE4 : someone wrote : Service pack 1 is still needed for the Y2K as it stops your cookies expiring in 00, from being 100 years old.
Versions of Windows in advance of 3.11, AIUI, store more than a single date for a file. This greatly extends the scope for problems, including date consistency. In the programs directory, see tz-check.* on Time Zones, etc.
I have seen a report of a system with YY years, designed to run permanently, that powers up by design in Year 00; and uses that as an indication of a non-set date; and so gives no output when at Year 00. OK so far ...
PC date rollover failure is but a minor problem.
THINK BEFORE SPENDING.
A description of the interaction of the RTC and the OS in a PC was found (in PDF) at Appendix F of Intel's C-E effect paper (it omits double-setting). Dallas Semiconductor TechBrief 8 was more Y2k-specific.
In many cases, neither the ROM BIOS nor the software OS of a PC will correctly handle the 1999→2000 transition (a recent system should be OK); but usually all should be well after the year is corrected. Installation of MSF receivers or connection to Internet time servers is generally overkill; just enter the new date, once, after 1999.
The Real-Time Clock RTC calendar chip DS1287 logic was designed to have no knowledge of "century", rolling smoothly from "99" to "00"; however, DOS uses part of the chip RAM to store its "century" information.
A normal DOS / Windows PC then goes ("flopback") to a date in 1980 (I have read that [some?] Windows 95 systems go to 1984-01-04); but most will work properly thereafter, after the date has been corrected once.
However, I have read that PCs with the Award 4.50 BIOS will need the date set EVERY day after 1999-12-31 - and "If your AwardBIOS was released between 26 April 1994 and 31 May 1995, you need to obtain an AwardBIOS update, or reset your system clock every day!". I have read that most Award 4.50g systems go to 1994/2094-01-01 at every boot; but that some 4.50g systems retain the "Century" and maintain the rest of the date correctly. I've also seen suggestions that the date range given is too narrow - for example: In news:comp.software.year-2000, 1999-05-09, Ron Martell (now <firstname.lastname@example.org>) wrote :-
"More correctly Award version 4.5x and then only for BIOS versions produced between certain specific dates. Pre 1994 and post 1996 versions have not yet been discovered to exhibit this particular behaviour. Most of the bad versions date from the last half of 1994 or the first half of 1995 but I have discovered examples with 1996 BIOS dates from one specific motherboard maker."
Both the version number and the release date are critical.
In article <email@example.com> of Tue, 14 Dec 1999 10:47:10 in news:comp.software.year-2000, by Tim Oxler :- "The Award Software BIOS, which was sold from April 26, 1994 to May 31, 1995 is the only BIOS that is incapable of sustaining a date of 2000/01/01 or greater."
My (UK, 1988) Amstrad PPC640 appears to have a slightly modified ROM BIOS; the RTC only stores YY, and there is no trace of CC anywhere in CMOS. But Int 1A/04 windows the YY into 1980-2099, and Int 1A/05 ignores CC. Evidently Alan Sugar used smarter staff than IBM did.
Lilla wrote (2000-01-02) :-
If you have an AWARD BIOS, then go to www.award.com and download their free Y2K test/fix Utility. There are known problems with AWARD BIOS manufactured between
- Sep 26 1994 - Apr 19 1995
- Oct 15-23 1996
Their text/fix utility will install a fix that will correct the problem.
Jim Walker has a YEAR.BAT which will reset the year of a PC to the given value, preserving Month, Day, Time.
Mike has a true BIOS fix, it seems, by reprogramming the EPROM : "Award v4.50G Bios eprom Y2K fix" in csy2kt 2000-01-13 00:46:19 GMT, Message-ID: <firstname.lastname@example.org>.
In an article 2000-01-18 21:39:33 GMT, Message-ID: <email@example.com> Henry Helgen cited Phoenix for Award BIOS - try this.
AIUI, either the PC preserves the month, day, and time; or it does not, in which case little but re-entry or replacement can help.
If it does preserve,
echo. | date | COLS 'rem * 'date 20+7 '2002 . -> rem date 18/12/2002
so redirect to a file and execute that, or, in DOS, use MASSEXEC. Remove "'rem * " after testing; edit annually. Adjust the COLS parameters if the format of the DOS date command does not match UK.
MASSEXEC, COLS via programs/; ZIP, PAS, EXE.
Start up carefully for your first time in 2000; consider CLOKCHEK.(PAS,EXE) and DATECHEK.BAT in my programs directory.
I believe that all DOS / Windows PCs showing this fault will normally flopback (indirectly) to ISO date 1980-01-04 = Fourth of January 1980, this being fully independent of the date display format (one can get nearby dates by entering BIOS Setup). Some, however, were saying that, in other countries, flopback is to April the First (which, I concede, would be a better choice). Please let me know if you have any really solid evidence for this, since I am satisfied that it is not so; that the difference is merely due to date order confusion in calendar reading. Only YYYY-MM-DD and formats with triliteral months are safe; and the latter will rarely be safe in '01..'31
I have been told, by Ian Galpin (DOS here is the OS in RAM, not the ROM BIOS) :-
It is also important to note that the 1980-Jan-04 date is only that used by DOS. The date in the RTC chip has gone back to 1900-Jan-01. The date used by DOS is one of several error conditions: 1980-Jan-01 - No RTC found 1980-Jan-03 - Invalid BCD number in RTC (such as a month number of '3A' or 'B7' for example). 1980-Jan-04 - Invalid date found in the RTC (i.e. a date before 1980-Jan-01 or after 2099-Dec-31. This occurs at boot-up, when DOS reads the RTC to get the date and time information. The date in the RTC is not changed by this.
See New Scientist letter, 971108; for BIOS also see links from Microsoft's White Papers page.
I have read "some Acer BIOS's powerfail to Jan. 12, 1991".
I have been told that POST is entitled to correct impossible RTC date/time to something possible, and to enter the Setup screen. Certainly this (rightly) does not always occur for non-DOS dates - if my Tandon 486/33 RTC is set to 1888-08-08 08:08:08 and booted, MS-DOS gets 1980-01-04, but the RTC retains 1888-08-08; but if fields are set to invalid BCD, Setup is entered. Setting the RTC to 1999-02-29 (sic) and rebooting, MS-DOS gets 1999-03-01, but the RTC retains Feb 29; setting 1999-02-31, MS-DOS gets 1999-03-03, RTC retains Feb 31. The PC enters Setup if booted with 1999-02-33 in the RTC.
IBM PC DOS 2000? Windows 98? Windows NT? Remember that PCs not running DOS will share the RTC hardware limitation.
For some BIOS date errors, some (page gone) Microsoft operating systems will correct the apparent year from 1900 to 2000 - this is OK until after 2000-12-31 ...
It may be useful to set the PC date forward a century, in DOS, immediately before final turnoff in 1999, so that its flopback is from 2099 to 2000. This needs proper consideration.
1999-03-13 : Using my int_test.pas, I have just set my Tandon 486/33 RTC (by direct write to Ports $70, $71) to 2000-01-00 23:59:45 and observed a clean transition 15 seconds later to 2000-01-01. Unfortunately but not unexpectedly, rebooting with the RTC set to 2000-01-00 gets one to 1980-01-04. It also rolls correctly from 2000-00-31 to 2000-01-01, but reboots from 2000-00-31 to 1980-01-04.
So, if one directly sets the RTC to either of those "00" dates after the last boot of Friday Dec 31st, and nothing reads the RTC till the following year, all will be as desired when one first staggers up to one's machine in 2000 - if it's like mine, that is.
It's a pity that the original PC OS was designed to use 1980 as the base year for file dates, and that flopback therefore is to 1980. If 1972 had been chosen, there would have been three advantages :-
It seems that, somehow, Windows >3.xx can boot 100 years ahead - watch for it!
Other errors will just start at the entry to local year 2000 (note that, globally, it takes about 24 hours to start a date), or at its first use.
Date failures involving local time/date will start in NZ (13 hours ahead of GMT at year's end) and will propagate around the world at nominally 15 degrees/hour to Hawaii and thereabouts, as is widely recognised.
But internationally-used systems, and the internal clocks in the better computers, are often GMT-based; so their problems hit simultaneously world-wide : after 9 hours of fixing Y2k local, the weary Japanese will be struck by Y2k GMT; whereas Y2k GMT will reach USA when some there are peacefully post-prandially slumbering in anticipation of local midnight.
This does not affect us here in the UK, naturally; but ISTM that a number of foreigners will have forgotten it, and some may remember it backwards.
The Sunday Times (URL includes 98/08/09, so they are not 4-digit) and the BBC report that, at the end of each year, Windows 98 gains two days or loses one. Microsoft has agreed, saying that this only occurs if Windows 98 is started within a particular but ill-defined second of the last minute of the year; a fix was being developed. See via here??
But Risks Digest 19.92 #11 says that it can occur any day, if one boots during a critical five seconds near midnight.
Don't let Windows 98 be booting during the minute before midnight, until the problem is resolved.
It seems that Win NT with SP3 & Y2k fix may have GUI problems if the year is advanced from 2000-02-29. It's probably prudent to avoid ever going through any invalid date, except when specifically testing.