To FootI do not give forecasts of general and social consequences; do not ask.
2007-01-21 : Some dead links are now underlined.
Apply throughout this section : in the great majority of cases :-
Replacing an old computer and system with a new one is generally a considerable upheaval.
There's no point at all in replacing an office or home PC just to cure the rollover problem. It may be worth replacing a BIOS, RTC, or motherboard of a machine that suffers Time Dilation; but maybe not if there is a reliable means of correcting and checking the time at boot. But forced reorganisation of software is expensive.
If there is, for example, a Y2k YY problem in a system running in Good Old Spreadsheet for Windows 3.x, then ISTM perfectly possible that it may be easier and safer to modify the existing code (which may well be at least partly understood) for Y2k compatibility than to move it to Impressively Superior Spreadsheet for Windows 98, since ISS98 will no doubt be significantly different from GOS3.x, with Hidden New Bugs instead of the old, familiar ones.
Replacement by purchase should not be considered as a global panacea; one must not allow a PHM to say "OK, chaps; I've ordered new systems to be delivered in 4Q99, since by then all products will have been tested compliant by actual use, and re-remediated. All Will Be Well."
Note, too, that last-minute replacement is likely to be a popular plan, supplemented by last-minute panic; demand may well exceed supply from, say, 3Q99 into 2000.
Similar considerations apply to larger systems. All IMHO.
There will be 2000-02-29, a Tuesday (as always for a century leap year); not all software recognises this. Probably all programmers remember the (Julian) 4-year leap rule; alas, in Gregorian, some know of the 100-year no-leap rule but not of the 400-year leap one which overrules it in 2000 and makes a simple 4-year rule viable for 1901-2099. Operating systems, among others, must be checked, for 2000 and other years.
In older PCs, the RTC, ROM BIOS and RAM OS just use the 4-year rule, which covers 1901-2099; modern ones may perhaps do better, though it hardly seems necessary - yet! Note that Setup & ROM BIOS and RAM OS may in principle report different Day-of-Week for the same date.
I'm told, though, that in an Olivetti M290S, with Olivetti DOS 3.30a, the CMOS date rolled from 2000-02-28 to 2000-03-01. If the 29th is omitted, subsequent Day-of-Week may be wrong.
TB reports a 486 VLB motherboard from 1994, with AMI BIOS, that skips 2000-02-29; SS has reported this with Award 4.50G and AMI BIOSes.
Some examples :-
(written 1998?)."returns the time in seconds since the beginning of 1900 (GMT of course). For many IBM systems, this second count is too large by 86400, because their programmers believe that February of 1900 had 29 days. This bug was around at least 10 years ago, and is still around on some of their mainframes that have TCP/IP installed."
On March 5th 1984 I was wondering why our accounts package was stamping all records with 29th Feb. Then I realised it wasn't the accounts package (which I'd written), but the OS. I can only assume that because it used Julian dates internally, somehow it incremented "29 Feb" to "1 Mar", converted that to "day 60" forgetting it was a leap year, and reset itself back to "29 Feb". As soon as I reset the date correctly to 5 Mar, it worked perfectly thereafter.
It's probably a good idea not to do anything rare or complex on the 29th of February, especially in 2000; if one doubts one's BIOS, don't boot on that day!.
UK FY 2000-1 is NOT a leap year; it has only 365 days, 2000-04-06 to 2001-04-05.
"0" is a digit, but "O" is not. Watch out for mis-typings, especially in Courier font; 0<>O. These are much more likely when two-digit years are used as name-components in 2000, and the digits "00" may not have other digits adjacent. This will affect name recognition and sorting. Proper validation, not always applied, will trap it.
Always setback by as much as possible, to reduce later ambiguity.
There are only fourteen different year patterns, ignoring Easter : a year can start on Sun to Sat, and is either Leap or not Leap.
A 58kB condensed Gregorian Calendar for 1970-2030, computed by my mjd_date, is at greg-cal.txt (week-cal.txt) (calendarhome has a longer calendar); it starts :-
Gregorian Calendar for A.D. 1970-2030
1970 Jan ThFrSaSuMo TuWeThFrSa SuMoTuWeTh FrSaSuMoTu WeThFrSaSu MoTuWeThFr Sa
1970 Feb SuMoTuWeTh FrSaSuMoTu WeThFrSaSu MoTuWeThFr SaSuMoTuWe ThFrSa
1970 Mar SuMoTuWeTh FrSaSuMoTu WeThFrSaSu MoTuWeThFr SaSuMoTuWe ThFrSaSuMo Tu
Any putting back of the date may lead to data being dated in the wrong order, and this may affect applications.
When it is necessary to have the Day-of-Year and the Day-of-Week right, but acceptable to have the year wrong, it is possible to use an earlier year, one still in the 1900s. The setback should be 28, 56, or 84 years, as the Gregorian calendar repeats every 28 years in between 1900 and 2100; larger values may reduce data ambiguity. BST change dates will repeat (assuming constant rules).
A DOS PC cannot be set before 1980+ (and some not so far), so for 2000-2007 a smaller setback must be chosen (UNIX can probably go back to 1970, allowing 28-year setback).
Year from Feb29 Day Matches Year from Feb29 Day Matches ... 1998-01-01 FALSE Thu = 1987 1981 1998-03-01 FALSE Sun = 1992 1981 1999-01-01 FALSE Fri = 1993 1982 1999-03-01 TRUE Mon = 1971* 2000-01-01 TRUE Sat = 1972* 2000-03-01 FALSE Wed = 1989 2001-01-01 FALSE Mon = 1990 2001-03-01 FALSE Thu = 1990 1984 2002-01-01 FALSE Tue = 1991 1985 2002-03-01 FALSE Fri = 1996 1985 2003-01-01 FALSE Wed = 1997 1986 2003-03-01 TRUE Sat = 1975* 2004-01-01 TRUE Thu = 1976* 2004-03-01 FALSE Mon = 1993 1982 2005-01-01 FALSE Sat = 1994 1983 2005-03-01 FALSE Tue = 1994 1988 2006-01-01 FALSE Sun = 1995 1989 2006-03-01 FALSE Wed = 2000 1989 2007-01-01 FALSE Mon = 2001 1990 2007-03-01 TRUE Thu = 1979* 2008-01-01 TRUE Tue = 1980 2008-03-01 FALSE Sat = 1997 1986 1980
The setback may be changed at the start of January or of March, with different tradeoffs; my program mjd_date can calculate such. A "*" marks (leap) years inaccessible to a DOS PC.
Please verify the above before actual use. Note too that, on the RHS, it counts a mismatch where one year is Leap and the other not, even if all earlier days match. Once dates begin to fully match, matches continue until a Feb 29 discrepancy.
+ : The 1980 restriction originated as a mere design choice, and, as a consequence, the (undocumented) DOS daycount is an unsigned 16-bit word with the value 0 representing 1980-01-01. It will be most uncommon for a program to access this word directly. It occurs to me, however, and this is supported by a quick look at some source code for a DOS rival, that one only needs to change a few occurrences of representations of 1980 in the code to representations of 1952 (the Accession year!), and the date range will be extended 28 years backward. Unrelated effects bound the DOS upper limit. File date notation would also need changing, too, which probably spoils the scheme.
A match of week pattern may not be necessary.
If one is prepared to use a false date, then it is quite likely that the week is not significant; in that case, go back 4, 8, 12, 16, or 20 years, since the leap year pattern repeats every 4 years within the lifetime of DOS. The advantage in going back many years is that the pseudo-dates may be easily distinguished from real ones; and also that the fix will last for longer (4-year setback fails after four years).
It is not always necessary to use the PC's native methods for Day-of-Week.
An embedded PC program written on the assumption that the PC (hardware, firmware, DOS) is fully compliant will fail if the PC is non-compliant and the program uses non-compliant aspects. But a program written for an assumed non-compliant embedded PC may yield a compliant system, even though using PC date & time.
For example : set the clock back by a multiple of four years to be within 1981-1999, add the offset to the year before using it, and (if required) calculate Day-of-Week yourself.
Lurking somewhere in an MS-DOS data structure - the CLOCK$ transfer record - is the day-count from 1980 (scan Ralf Brown's List for the fifth CLOCK$); just add the missing years at 1461 days per four, add your favoured offset (in 0..6), and then do mod 7 to get day-of-week.
Or use my dateprox.pas methods (or another) to get CMJD and then DoW from Y M D.
Or tell it the DoW at turn-on, and increment it whenever longint $40:$6C drops.
One may be able to run the RTC and OS with a false date, yet present the correct date to an application, provided that the application itself is compliant.
For 4*n year setback, for example, chain into Int21/2A to increment CX and recalculate AL before return (but remember Int21/2B, & Int1A too). Untested.
Can sometimes be accommodated by 84-year setback (1914 fully matches 1998, 1915 1999, 1916 2000; but not the preceding and following year pairs) : see The Date of Easter Sunday.
The above assumes that dates are computed by standard algorithms. If a look-up table is used, it may be too short.
On the question of whether systems should be on or off at the entry to 2000 : large-system users will understand their own systems and needs, and should require no advice.
Pure opinion follows -
Small-system users taking raw line power, if uncertain of their supply, should switch off for system-protection reasons, unless operational reasons necessitate accepting the risk of being on; and should remain off until, to judge by incandescent lights (or better) the power seems on and stable in 2000. Those using good system protection and a UPS may feel it safe to remain on. There might be cause, however, to put communicating applications in an "extra-suspicious of data" mode; to back up data late on 99-365, and more frequently thereafter until things look safe.
By the way, a few years ago JEP had a nice bit in BYTE about the occasion when (IIRC) a truck hit the pole carrying his local 3.3 kV to 110-0-110 V transformer, causing the input to connect directly to the output - IIRC, it considerably improved his knowledge of the actual performance of various surge protectors.
Remember that if line power fails, it may come and go repeatedly; and this is not good for complex, unprotected systems. As a general rule: if power fails, switch off before it reappears (unless you know better).
And that, if you plan to be off and stay off, you should be able to achieve this, and only need test for "off" rollover. If you hope to be on, you need to test both - outages due not to y2k.tech but to y2k.party are quite possible, as the drunks ...
GLS wrote : Shut down and reboot. Then check the system date and correct if necessary. The vast majority of machines in use today will operate correctly if this procedure is followed. Many older machines will have problems if they are left running during the rollover.
CMOS Latency is another reason for not having a PC running at rollover; and analogous effects might occur in other systems.
One class of problems will occur, or begin, at the moment when the date becomes 2000. This moment occurs in every Time Zone setting which is used in the system; and therefore one should think about any which may be in use.
Be aware, for example, that the kernel of a properly set UNIX system keeps GMT (UNIX predates UTC) internally, and supplies a count of seconds (from 1970-01-01 00:00:00 GMT) to applications as required; Tony Walton writes that UNIX will supply timezone information, language information and library calls for applications to make use of this but at no time should an application change the kernel's idea of the time to match a local time zone. The kernel, therefore, is Y2k-immune.
However, sometimes a system appears wrongly configured in such a way that it retains the "TZ=GMT+8"/"TZ=PST" environment setting that the software was "born" with, with the internal time wrongly set to give compensating errors and an apparently correct display.
I think this means that the worst-case Critical Moment List must include, in general, 2000-01-01 00:00:00 in :-
However, some of these will only apply if applications have been written to compensate for a mis-configured UNIX core. One can see the advantage of living in the correct hemisphere and at the correct longitude!
AIUI, aircraft go so fast that fliers are aware of such problems; there might be a maritime problem, say with inter-TZ ferries (I recall that, on the Stockholm to Turku ferry, the clocks had bifurcated hour hands...).
This refers to the "Century" byte of the RTC being written by the ROM BIOS call Int 1A/05. It is said that, in some PCs, the "Century" is not written as expected.
MS-DOS sets the date or time with an Int 21/2B or Int 21/2D call, either of which writes both date and time to the RTC, using the CLOCK$ driver, which uses both Int 1A/05 (date) and Int 1A/05 (time) calls.
Note that each of the Int1A date and time calls is specified to write only the expected one of date and time; and the date call should set the century byte; see, for example, Ralf Brown's List. However, I am told that in some BIOSes a call to Int 1A/04 can update CMOS if Y2k rollover is detected.
DAS of 2000TOOLS Group, Inc describes it specifically as a failure of Int 1A/05.
It seems to me, however, that one should not expect the "Century" to be autonomously corrected by ROM BIOS code; the calls are not specified to do so. Nor do I really think that POST has the right to interfere (though I have seen it written that it does). The "Reading" date and time calls of DOS ought not to write anything back. And I believe that the date and time "Writing" calls of DOS do, through Int 1A/05, write the "Century". In fact, I see no more than a failure of over-expectation.
Many current standards (X12, EDIFACT, VDA, OFTP, etc.) for electronic commerce data specify 2-digit year fields; this is changing. Incoming data must be checked with care, as its value or format may be defective (after Chris Newport, NetUnix; Randall Bart; US GAO Y2K EDI Report, in csy2k).
An E-mail about y2k-mfaq.txt from Jeffrey Soreff (USA), including "I'd put the embedded systems into the very first description of the problem, of equal importance with the enterprise software, perhaps by noting that "record" can mean a single instance of a data structure in the RAM of a piece of microprocessor-controlled equipment. Perhaps the example there should cite numerical integration across the date boundary, with the attendant negative spike in the integral." shows that so far I've grossly under-emphasised this aspect.
Others will know more than I; URLs?
Mark A. Frautschi, Ph.D. - "Embedded Systems and the Year 2000 Problem".
See also Year SetBack and 2000 is Leap, above. General Y2k site with diagnostic tool information : Patrick Bossert.
Michael Saunby <Mike@Chook.Demon.Co.UK> wrote :-
Ministerial Group On The Millennium Date Change (Misc4) Terms of Reference - "To drive action in the public and private sector, including the national infrastructure, to prevent damage from the failure of electronic systems related to the Year 2000 date change"
Ministerial Sub-Group On The Millennium Date Change (Misc4(P)) Terms of Reference - "To drive action across central Government Departments, Agencies and the wider public sector to prevent damage from the failure of electronic systems related to the Year 2000 date change"
Presumably the P stands for "Public"
There were details of the composition of those cabinet committees at cabcom.
Pity they don't know that the Millennium is after 2000.
Randy Guidry <randy@y2knews.com> wrote :-
In Resolution A/RES/52/233 passed on June 26 by the General Assembly of the United Nations, the international organization appealed to its member states to quickly begin aggressively addressing this aspect of the formidable year 2000 computer problem, calling upon world governments and international businesses to share compliancy information and techniques to speed up the remediation process.
The complete text of the resolution is available for perusal on the Y2K News magazine Online website. (No DNS 20011122?)
On the whole, I don't intend to say much on this subject, other than what is in year2000.txt. However :-
To subscribe, send a blank email message to uk-y2k-action-subscribe@egroups.com
List owner: Paul Swann (pswann@easynet.co.uk)
List charter: uk-y2k-action is a forum for -
* the exchange of information on Y2K
* the development of mutual support between activists
* the co-ordination of community preparedness initiatives in the UK & Ireland
I do not give forecasts.