Year 2000 Page, Part 1.

I do not give forecasts of general and social consequences; do not ask.

2007-01-21 : Many dead links are now underlined.

The Year 2000 Problem : 19xx→20xx

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.

Visible Computers

Static Effects

Cosmetic

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 2³² 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.

Windows Settings

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.

MS-DOS Settings

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.

Significant

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.

Unknown Effect

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/.

Internet News and Mail

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.

Web Cookies

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.

Recreational

Windows 9x, etc.

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.

Unset Dates

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 ...

Dynamic Effects

PC date rollover failure is but a minor problem.

THINK BEFORE SPENDING.

PC : Failure to Transition Properly

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.

        echo. | date | COLS 'rem * 'date 20+7 '2002 .
->      rem date 18/12/2002

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.

A Pity

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 :-

• The file date system would have covered 1972-2099, avoiding the two complications with 2100 (divisible by 4 but not Leap; and starting a third second digit);
• Flopback is already to the correct month and year for the first UK working day of 2000; and using 1972 the day-of-week would also be correct;
• Indeed, then, it would have been possible to remediate suitable systems for "classic" Y2k by running 28 years slow.

Other Boot

It seems that, somehow, Windows >3.xx can boot 100 years ahead - watch for it!

Other Dynamic

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.

Windows 98 - any year/day end

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.

Date Changing

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.