To Foot2007-01-21 : Some dead links are now underlined.
Presuming that all new PCs will operate without problems in and for a while after 2000 (ignoring Apps) : after 1999-12-31, will there be a demand for 19xx-compatible PCs?
Remember that any system acquired after 1999 may need to be checked for 19xx compliance, in so far as it may be used with "historic" data. Indeed, all systems should be checked for retaining needed 19xx compliance in and after 2000.
Before testing, ensure that your system is in proper order, properly backed up, and isolated. Be prepared for total corruption. Where possible, use a separate, dedicated test system.
Test that backups made before 2000 can be restored before and after 1999; and vice versa. There is a certain difficulty in ensuring that the system is safely backed up before doing this ...
Consider whether aspects of the work may be load-dependent; I have read of a date bug in a background garbage-collector.
Watch out for year or date appearing where it is not really needed - for example, as a random-number seed.
On a PC (or similar) be sure that the small battery which runs the CMOS/RTC while the machine is off is in adequate condition; some tests are potentially misleading if the battery is not reliable.
Beware of other processes running on a PC which may pick up erroneous timing.
After any tests involving significant alteration of date/time in a PC, it is prudent to reboot. This ensures at least a consistent degree of consistency.
The hardware of a PC is initialised at turn-on. Some PCs also have a dedicated hardware "reset" button. A PC may also be restarted by CtrlAltDel, a "warm boot". The differences are not always clearly understood.
On Fri, 20 Nov 1998 in news:uk.tech.y2k, Roger J.Hamlett wrote :-
The 'reset' does a processor reset. Code starts from exactly the same spot as on a 'cold boot'. However it differs in some specific ways from the genuine 'cold boot'. Firstly some cards in the PC may not use the 'reset' line on the bus, instead implementing 'power on reset' circuits. These will not be reset. Secondly the memory contents, though slightly changed at the 'page boundaries', by the memory 'check' (the BIOS does not really perform a 'memory test'), will still contain the data that was in the machine, when the reset button was pushed.
Effectively there are :-
1) Cold boot
2) Reset
3) Warm boot
in descending 'order of potency'.
In 1984, with the introduction of the AT, the PC was given date/time retention by the addition of a Real-Time Clock chip (Motorola MC6818 or 146818, at a guess). I have the data sheet for the RS146818, and a technical manual for the Amstrad PPC640 which includes HD146801 data. The standard RTC has no century rollover errors at all; it ignores by design the two highest digits of the year, and gaily proceeds in the manner ordained by Julius Caesar at a rate of one year per 365.25 days. It does ignore the upstart Pontiff and his reduction of this figure in 1582 to 365.2425, even though the Papal scheme does seem to have caught on; but, as it happens, we do not need to allow for this until the year 2100.
If the date and time are written in ISO 8601 4-digit form as CCYY-MM-DD
hh:mm:ss, then each biliteral is stored in the RTC of a PC as a byte of
two nibbles, where the nibbles are decimal digits.
Byte CC is usually stored, passively,
in CMOS RAM in the RTC chip, at $32.
Each of the other bytes is stored in an active register of the
RTC clock/calendar chip, and the set is updated once a second.
Care must be taken in reading the RTC, to avoid reading during
an update.
The BIOS/DOS converts the time into ticks-from-midnight, where there are Hex 1800B0 18.2 Hz ticks per day, and increments this blindly every 55 ms. It converts the date into a count from 1980-01-01, and stores this in an obscure spot. I can now locate this number in low memory by underhand means; but normally, system calls are used to get YYYY-MM-DD and DoW.
The Day-of-Week register in the RTC appears, from tests on one RTC, to be incremented at midnight, not to be calculated from Y M D, and to be ignored by MS-DOS.
I have seen mention of a PC in which at rollover the century byte was incremented from nibbles '19' in a binary (not BCD) fashion to '1:'. Ouch!
It is said that the updating, as 1999 becomes 2000, of the customary RTC Century byte at Bank 0, 032h, may be delayed, possibly by as much as one DOS tick (55 ms), in some systems, though the new, automatic byte in some RTCs at Bank 1, 048h, may be changed during the update at RTC midnight. "RTC Confusion" by Solace Consultancy Services Ltd, "The 'Latency Problem'" by PC2000, and "System Compliance Categories" by Due Diligence 2000, Inc. referred.
Their pages seem plausible - but it occurs to me that the latency may be greater, as the RTC and MS-DOS run at different approximations to the correct rate. If the MS-DOS clock is slow, there may be a while (easily seconds) after RTC rollover before MS-DOS rollover, and ISTM that only at MS-DOS rollover will the "passive" byte be updated. If the MS-DOS clock is fast, the reverse might occur, with a brief visit to 2099.
I don't know how to work Bank Switching in the RTC; the data sheet ought to be examined to see how long it takes. It could, and should, be near enough instant.
Whatever the likelihood of an actual problem, the risk can be avoided by turning a PC off before any of its clocks roll over into 2000, and leaving it off until the RTC (and any externally-connected clocks) have certainly finished entering 2000. Then, after turn-on, set at least one of Date and Time until both are correct. Then (this should do nothing for the PC, but helps user confidence) reboot fully, and verify Date and Time.
If the machine must be left on at rollover, all will be safe in this respect if it does not access the RTC "during Midnight"; if it does so access, there may be a Century error, which may not subsequently be trapped.
Never allow midnight to occur during early booting.
One ought to establish, before 2000, whether one will have the Award BIOS problem, and, if so, what to do.
Otherwise, the world is satisfied that correcting the PC date once, after 1999 but before the date is subsequently first used, does what is needed, unless TD occurs.
If uncorrected rollover, RTC battery failure, uncorrected Y2k testing, etc., occurs, then the date/time at next boot will be implausible with reference to the date/time at previous boot; that is why I have my clokchek.pas / clokchek.exe called in the autoexec.bat of my 486 PC. It will also, as it happens, catch any TD jump, unless small, though it predates the TD saga. This program is free of both charge and guarantee.
And if uncorrected rollover or RTC battery failure, etc., occurs, then the date at boot will in fact be 1980 ; that is why I have written datechek.bat which can be called in the autoexec.bat of a PC. This routine is free of both charge and guarantee; it will need adjusting for national settings and to some extent for DOS version, but is easy to test.
And my int_test.pas / int_test.exe will inter alia enable the so-called "Natural Time Progression" method to be refuted, while showing what actually happens (manually, or by command ART 1); it will also show the once-a-second transitions of the RTC in sordid detail (current or chosen time), and it will also run tests which should show TD in action, if it occurs in the system more or less as I believe the reports imply (this is not fully verified, as my machines do not show TD). This program is free of both charge and guarantee.
1999-05-18 : In int_test.pas, new ASM code by Vlado Nikiforov has made RRRTC loop 15% faster on my 486/33.
It occurs to me that the date rollover problem is being wrongly corrected, by fiddling with CMOS byte 32h.
The RTC itself runs without error (if properly treated), century on century, giving the last two digits of the year.
The right answer is to patch MS-DOS RAM BIOS - which is what actually sets 1980-01-04 - to ignore the century byte, and to window, just like my Amstrad PPC640 does, the YY digits into 1980..2079, which should see most of us out. Or to release upgrades to existing MS-DOS - Microsoft could do this, the problem must be in one of those few files that SYS always copies - easy to distribute - make it, in honour of the pseudo-millennium, an 0.001 release increment, so DOS 3.30 becomes 3.301, etc. - and VER will not show this change. It would for compatibility write the century, if changed, to the RTC.
An alternative may be to use a driver, loaded first in config.sys. It would read the RTC (as yet unaffected), and, in its initialisation code,
In a system with date errors, large amounts of data may be prematurely purged if the date is advanced; be careful when testing.
Pam Hystad wrote, about date advancing :-
I have to interject a caveat here: as some of us have discovered, nasty things can happen to date-sensitive applications when a PC is time-warped to 2000. It would be wiser to advise people to *first* make a (recoverable) backup, then check for and disable programs that may be adversely affected by being advanced 18 months. Software with expiration dates, software with auto-update features, schedulers, some email and messaging software, some accounting programs, some auto-archiving or disk management-type utilities -- these are the types of commonly used programs that will cause problems. Since many users don't really know what's installed on their PCs, or how their programs work, the safest method of time-warping is to power up from a bootable floppy.
Ron Martell wrote, about date advancing :-
That is one test that no one should do, except possibly those who also have a penchant for playing Russian Roulette with all cylinders loaded. Expiry of time limited software licenses, automatic rollover of accounting data, purging of email, newsgroups, and appointment calendars, are just some of the more common occurrences that have happened to people who have attempted this particular piece of idiocy.
Note that some systems cannot have their date reduced.
AIUI, the Windows 98 public beta versions seize up utterly if they see a boot date after 1998 - whether or not the date is genuine. It is also said that Pentiums seize up irrevocably on (sic) 2000-01-00.
In addition, I suggest that no-one should push the clock forward without the explicit consent of at least the next level of management upwards, whether it be the kids, the spouse, the parents, or some more formal business arrangement.
It would also be wise to get the agreement of at least the next level down; consider this post-disaster dialogue in the IT meeting room :-
Senior Manager : "The Board and I are most grateful to Manager and Staff for the considerable effort put in to mitigate the damaging effects shown up during the "Date Ahead" test that Manager began last week, unfortunately just before I announced that the Chairman of the Board was about to visit here".
Manager : "The effects were unpredictable; but, under my guidance and leadership, my staff (and I) have toiled nobly; the Chairman's urgent data request was fulfilled, with only a week's delay".
Staff (sotto voce, but audibly) : "If Manager has told us what he was about to do, we would have reminded him of our memo dated a fortnight ago explicitly warning of ... ...".
Senior Manager (slightly later, in office) : "Miss Secretary, please bring the Staff Chart and the promotability records for IT Section; I feel a need to institute a couple of changes, pre-emptively ...
In Europe, be extra careful when testing systems built under US
influence during those weeks in Spring and Autumn when American
clocks are set ahead for Summer ahead but ours are not.
Many in the non-Tropical Southern Hemisphere must be careful for
longer ... .
[US DST rules change after 2006, increasing the duration of
difference.]
In general, be sure that at most one part of a system implements the time change; the user, the IT staff, the BIOS, Windows, ...
A bug is reported in MS VC++ libraries; if DST should start on April 1st, as it does in 2001 (and once per seven years on average) VC++ uses April 8th. Fortunately, this cannot affect Europe, where BST starts in March. MS tends to confuse the last X-day of a month with the fourth X-day.
My HUNTTEST.ZIP contains a set of zero-length test files with various dates, most valid and some invalid, in the range 1980-00-00 to 2107-15-31; my DOS program HUNT can display all filedates correctly, as YYYY/MM/DD (use "/4"). There is a program DOSSTAMP via my programs/ which can set any DOS datestamp, valid or not, on a file, and can create dated, empty files.
It is reported that some versions of TOUCH.EXE are not 2000-compliant. For example, some from Borland.
Note that, in order to fit into a 16-bit field, MS-DOS-compatible file times always have the seconds even. The file date storage format, YYYYYYYMMMMDDDDD-hhhhhmmmmmmbbbbb, (though not DIR) handles 1980..2107 (Year=1980+YYYYYYY), but, if handling Date-&-Time as a 32-bit longint, be aware that it goes negative in 2044 - xor both sides with $80000000 before comparing for order.
2000 is a Leap year - Monday 2000-02-28, Tuesday 2000-02-29, NoDay 2000-02-30, NoDay 2000-03-00, Wednesday 2000-03-01 - test it, especially with library functions, particularly C/C++ ones and those derived therefrom.
Note that the 4-100-400-year rule set does require the correct year, not a count from 1900 or 1980. The errors available should now be obvious.
Internet News should tolerate 2-digit years in headers after 1999. But, according to Son-of-RFC1036 sec. 5.1, which many people respect : "Two-digit year numbers can, should, and must be phased out by 1999". Ha! See what yours gives; and see Year 2000 Page, Part 1.
Visible present use of 4-digit years does not prove compliance; the "19" may be hard-coded - a case has been reported of an organisation caught by this.
The Daily Telegraph, 1999-01-15, p.2, top right, reports that the Heads of all China's airlines are ordered to take a flight on 2000-01-01, to test for success in Bug-handling.
We live, it seems, in interesting times; and the Chinese example should be commended to the responsible leaders in our own country.
As I have not personally tested the available auto-testers, I make no recommendations myself.
However, the respected Ron Martell (Duncan, BC, CA) has written :-
About the best that I have found (I haven't tried them all) is the OnTrack Y2K Advisor from www.ontrack.com. The free version does a comprehensive test sequence and then gives you a plain language report describing exactly what the problems are and what you need to do in order to correct or compensate for them.
PC Magazine Online has a list of Third-Party Year 2000 Testing and Analysis tools : BIOS/RTC Testing Utilities & Patches, Software Analysis & Conversion Tools.
Those running date-dependent systems that interconnect with others need to be prepared for the possibility or probability that, while they themselves are happily set to the correct date and processing normal data, they may unwittingly connect to or be connected to by associates who are at the time (or have been) doing their own Y2k testing and so have set false dates and are sending false (or mis-dated real) data.
And those who are Y2k testing need to beware of connections with those who are not; but that is well known.
No doubt organisations such as banks can and do take multiple precautions to ensure that their wrong-date systems cannot connect to the real-time world; but smaller, less IT-skilled bodies should not be relied on to be error-free in this matter.