Filename: YEAR2000.TXT
WWW URL: http://www.firmware.com/support/y2k/year2000.htm
FTP URL: ftp://ftp.firmware.com/y2k/year2000.txt
Author: Terry Slade, Micro Firmware Technical Support
Revision: 07/23/99
Summary: Detailed information on the Y2K date rollover problem on PCs
and how it relates to the PC's system ROM BIOS and RTC.
Contents:
1. Introduction 2. A Technical Explanation of the Y2K Date Rollover Problem on PCs 3. Y2K Compliancy of Micro Firmware BIOS Upgrade Products 4. Solutions to the Y2K Date Rollover Problem on PCs 5. Testing PCs for Y2K Date Rollover Problem 6. Does a Y2K-compliant BIOS Make a PC "Year 2000 Compliant"? 7. Time Dilation / Crouch/Echilin Effect / Time-leap 8. For more information:
There are some interesting and important issues concerning computers and the year 2000. Collectively, these issues have come to be known by various names such as "the year 2000 problem" or "the millenium bug" or just "Y2K". Basically this has to do with how various computer software and hardware will deal with the date change from DEC 31, 1999 to JAN 1, 2000 and with how computers and software will handle dates beyond DEC 31,1999.
There are many aspects to this problem, which affect all types of computers, including mainframes and PCs. There are hardware, firmware, and software issues. Also affected are embedded systems - the billions of chips and systems that are built-in to various machines.
On PC systems, the Real Time Clock (RTC) chip will not roll the date over to the year 2000 without some help. Many newer BIOSes will account for this. On most older systems the rollover problem can be corrected by just typing in the date manually.
We began to investigate this issue in 1996 as we were starting to get phone calls from customers and others wondering if our BIOS upgrades have this problem or solve this problem. It is the purpose of this article to address this issue as it pertains to PC hardware, the PC BIOS, and our own BIOS upgrades in some detail. Please note that there are additional date-related issues concerning PC operating system and application program software. These are not issues that we will investigate or address. We would suggest looking at the web sites listed at the end of this document as a starting place to begin learning about any year 2000 issues not addressed here.
The specific problem that occurs on PCs is that, under most older BIOSes, if the system is powered off during the date change from DEC 31, 1999 to JAN 1, 2000, when the system is turned back on the DOS date will be indicated as 01/04/1980. This is easily solved by just setting the date correctly with the DOS DATE command. The system should keep the date correctly from then on. If the system is running at midnight on 12/31/99, it may roll over the date correctly, but still show a date of 01/04/80 when first rebooted. After setting the date correctly it should keep the date properly from then on. On some systems, other solutions may be needed, since it may be critical for the date change to be handled automatically, without having to depend on someone remembering to set the date. This problem will manifest in various ways under various different operating systems.
Also - see our web site for information on our Flash 2000 card, which is an 8-bit ISA card with a ROM extension that corrects for the Y2K date rollover problem. A separate text file, FLSH2000.TXT, discusses that card in detail. That file is available on our web site and ftp site at these URLs:
http://www.firmware.com/support/y2k/flsh2000.htm
ftp://ftp.firmware.com/y2k/flsh2000.txt
The year 2000 date change problem on PCs is caused by the way the date is stored in the clock chips used on PCs. All PCs (besides XTs) have a Real Time Clock (RTC) which keeps track of the date and time when the system is powered off. This is usually a dedicated chip, but the RTC may also be integrated into an I/O chip or the main chipset. IBM used the Motorola MC146818 in the original AT. The RTCs in all PCs since then are based on this chip. The RTC chip is usually also used to store CMOS setup values. The battery on the PC motherboard is present to hold the values stored in the clock chip and to keep the clock running. (Some clock chips, such as the Dallas 1287/1287A/12887/12887A, contain the battery within the chip). The RTC has dedicated registers for seconds, minutes, hours, days, months, and years, which it increments itself. The register that holds the year value holds only two digits, so 1999 is stored as 99. The year 99 will roll over to 00.
The clock chip does not have any way to keep track of the century by itself. The original PC BIOS specification does provide for keeping track of the century by way of a particular byte in CMOS RAM (32h), which also is normally located in the clock chip. This byte is updated whenever a BIOS call is made to set the date (INT 1Ah Function 05). One time this happens is whenever the DOS DATE command is used to set the date. With some Y2K-compliant BIOSes, the century byte is also updated whenever a BIOS call is made to read the date. DOS makes a BIOS call to read the date on every boot, so it can set up its counter. DOS does not make a BIOS call when the DOS DATE command is used to READ the date, since DOS is already keeping track of the date, once the system is booted up.
When a PC is booted up, DOS gets the date and time from the BIOS, which gets the date and time from the clock chip. As long as the system is powered on, the clock chip and DOS are both keeping track of the date and time separately and using different methods. The clock chip uses a signal from an oscillator (which may be built-in to the chip) to increment its clock. DOS calculates the date based on the number of days since 01/01/1980 and calculates the time based on a counter maintained by the BIOS in the BIOS Data Area. DOS then increments its clock using this counter, which is based on a different oscillator than the clock chip is using. As long as a PC is running, DOS will maintain the date using 4-digit year format and the date will roll over properly from 1999 to 2000. However, DOS is maintaining its date and time separately from the clock chip, which is using a 2-digit year format. DOS does not update the date or time in the clock chip unless the DOS DATE or TIME commands are used to set the time or date. (or actually if a BIOS call to read or write the time or date is made). So if a PC is running at the turn of the century, DOS will advance the date correctly but when the system is then powered off and back on, DOS will retrieve the current date and time from the clock chip which will include 00 for the last 2 digits of the year and 19 for the century. The clock chip does not have a means to account for the century itself, and also has no way to alter the byte in CMOS RAM that the BIOS uses to keep track of the century. When the DOS DATE command is used to set the date to the year 2000, the century byte in CMOS RAM will be updated. Most newer (Y2K-compliant) system BIOSes account for this problem by assuming that if the 2-digit year accessed from the clock chip on bootup (or whenever a BIOS call is made to read the date) is 00 (or less than some value such as 80), then the century byte is set to 20.
Windows 3.x will have no effect on this problem. That is, if the system is running under WIN3.1x over the century change, the date should roll over properly, just it would under DOS, but after rebooting the system it would show a date of 01-04-1980.
Windows 95 also does not correct for the date rollover problem, although it may appear to if testing is not done carefully.
Windows 98 does correct for the date rollover problem on, however this correction is thwarted if the system is booted from a DOS diskette on the first boot after the century change. The date would then be 01/04/80 and when Windows 98 is restarted it will keep this date until manually changed.
Keep in mind that software issues are a separate matter. A PC system that is declared to be "century-compliant" is not immune to all kinds of problems caused by software that is not century-compliant.
Another aspect of the year 2000 problem concerns the fact that leap years occur every four years EXCEPT when that year is a century year (such as 1800, 1900, 2000, etc.), in which case it is not a leap year - EXCEPT every four centuries. The year 2000 is a leap year. This could be a problem in some software that does not properly account for leap years. This doesn't seem to be a common BIOS problem. This would be due to the fact that standard RTCs will treat every four years as a leap year, so they should not cause any leap year problems until the year 2100. We have seen some BIOSes which will not allow a date of 02/29/2000 to be manually entered in CMOS setup, but this does not prevent that date from being handled properly otherwise.
Micro Firmware BIOS upgrades which are based on Phoenix 4.05 code are Y2K compliant. These include our part numbers I4HS10, I5HS10, I5HS15, I5HS20, I5HS25, I5HS30, I5HS35, I5JS40, I5JS45, M4HS45, M4HS45G, M4HS45GC, M4HS45GP, M4HS50, M4HS60, M5HS10, M5HS15, M5HS20, M5HS60, P4HS00, P4HS10, and P4HS20. All revisions of these BIOS upgrades are Y2K-compliant BIOSes.
Older revisions of our BIOS upgrades based on Phoenix 4.03 code are not Y2K-compliant. The current revisions of all of these upgrades are Y2K-compliant.
The following chart indicates which revision of each of our 4.03 BIOS upgrades is needed to fix the year 2000 date rollover problem:
MFI Part Number Minimum Revision Needed for Y2K Fix
M3GS20 4.03.6.09 Released 02/04/97 M3GS30 4.03.6.12 Released 02/21/97 M4GS20 4.03.6.09 Released 02/24/97 M4GS30 4.03.6.14 Released 02/26/97 M4GS25 4.03.6.17 Released 01/30/97
The M4GS25 BIOS upgrade is a flash BIOS. The current revision can be downloaded from our updates page at:
http:/www.firmware.com/support/updates/
The other 4.03 BIOS upgrades listed above are supplied on EPROM chips. Please contact us for information on replacing older revisions of these BIOSes.
The I4GS10 BIOS is a flash upgrade based on 4.03 code. This BIOS is not Y2K compliant, but has been replaced with the I4HS10 BIOS, based on Y2K-compliant 4.05 code. The current I4HS10 BIOS (which will flash in on top of the I4GS10 BIOS) can be downloaded from our updates page:
http:/www.firmware.com/support/updates/
Note that any responsiblity to support or update a BIOS on any PC system rests entirely with the manufacturer of the motherboard and/or system. Companies such as Phoenix, AMI, and Award produce only the base code used in creating BIOSes. Normally the manufacturer of a motherboard will adapt code licensed from a provider of source code to create a BIOS for a specific motherboard. Phoenix, AMI, Award, etc. normally have no control over what is done with the source code and do not have any means to provide an updated BIOS for any particular motherboard. Micro Firmware has no plans to produce any new BIOS upgrades for the purpose of providing Y2K compliancy.
Unless a PC is left on all the time and is performing a critical task, we do not recommend purchasing a BIOS upgrade just to fix this problem, as (in most cases) it can be fixed very simply as described elsewhere in this document by resetting the date on January 1, 2000.
What do we mean by a Y2K compliant BIOS?
A Y2K compliant BIOS will handle the year 2000 date rollover problem at the BIOS level. When an operating system or application program makes a BIOS call to get the current date (INT1Ah Function 04h), if the BIOS finds that the year value in CMOS RAM is 00, it will change the century value in CMOS RAM from 19 to 20.
Any PC BIOS should update the century value in CMOS RAM whenever a BIOS call is made to set the date. A Y2K compliant BIOS will additionally update the century value in the RTC anytime a BIOS call is made to read the date if it finds that the year is 1900 (or within some specified range). A Y2K-compliant BIOS does not make a PC completely Y2K-compliant. It only makes a system Y2K-compliant at the BIOS level. The PC will still not be compliant at the hardware level, since the RTC still may return an incorrect date to an operating system or application if the BIOS is by-passed and the RTC is accessed directly. (Note that this can only occur if the century value has not already been changed). Software that accesses the RTC directly is not common and would be considered non-Y2K-compliant. Y2K-compliancy at the hardware level is not of concern in most cases. The definition of Y2K-compliancy for PCs that has come to be the industry standard does not include the hardware level. This is explained on the website of the PC Year 2000 Alliance:
Also, a Y2K-compliant BIOS will have no effect on any Y2K problems in any software programs. Any number of date-related problems may be present in operating system or application program software. For a system to be declared Y2K-compliant, all of the software should be Y2K-compliant.
There is one date-related issue that we know of in our Phoenix 4.03 and 4.05 BIOS upgrades. The Date field in CMOS setup will allow a year value only up to 2030. This is only a problem with entering the date manually into this field in CMOS setup. The BIOS will not prevent the date from advancing correctly past 2030. If CMOS setup is entered after the year has advanced beyond 2030, the correct year value will be seen in the Date field. If this field is accessed and the year value is changed, it will again be subject to the 2030 limitation. The date can then be set at the DOS prompt and will continue to be kept correctly.
Solutions include manually setting the date after the century change, upgrading the system BIOS, installing a TSR program, installing a card with a BIOS extension (such as the Micro Firmware Flash 2000 card), replacing the clock chip, and replacing the motherboard. Each of these solutions has advantages and disadvantages. Note that none of these solutions (except replacing the clock chip) results in a "completely Y2K-compliant" PC (and even then - we are not counting the software).
Manually resetting the date:
Advantages:
No cost (assuming no one is being paid to do it).
Nothing to install.
Disadvantages:
Requires manual intervention at the century change.
May be impractical for sites with a large number of PCs.
Some programs may need to run uninterrupted overnight.
It may be forgotten until after problems have been caused by
the incorrect system date.Upgrading the system BIOS
Advantages:
If an upgrade is available this is a preferred solution.
Requires no manual intervention at the century change.
Disadvantages:
For most systems with this problem there is no BIOS upgrade
available.
In some cases the BIOS upgrade will be provided by a party
other than the motherboard manufacturer and will not be free.Installing a TSR:
Advantages:
Requires no manual intervention at the century change.
Disadvantages:
May be removed when the TSR program itself or AUTOEXEC.BAT is
accidentally deleted or when hard drive is replaced or
reformatted.Replacing the clock chip:
Advantages:
Fixes the problem at the root.
Requires no manual intervention at the century change.
Disadvantages:
Only certain types of clock chips can be replaced. The clock chip
may be integrated into the chipset or it may be soldered onto the
motherboard. Cost is about $25.00.Flash 2000 card:
Advantages:
Requires no manual intervention at the century change.
Cannot be accidentally erased (as with a TSR program).
Disadvantages:
Cost of the card.
Takes up an ISA slot.Replacing the motherboard or system:
Advantages:
Requires no manual intervention at the century change.
(Most new motherboards will have a Y2K-compliant BIOS, very
few, if any, will have a Y2K-compliant clock chip).
Disadvantages:
High cost. (cost of the motherboard, plus other components
needed such as CPU and RAM, cost of the service).
We have written a test utility, Y2KTEST.EXE, which is supplied with our Flash 2000 card and which can be downloaded free of charge by anyone from our web site or ftp site:
http://www.firmware.com/support/y2k/y2ktst.exe
ftp://ftp.firmware.com/y2k/y2ktst.exe
This is a small DOS program which can be run under Windows 95, although it may be more accurate if run under a clean DOS boot. We provide this program so that any PC can be tested to see if it may need a solution for the date rollover problem and so that any PC in which the Flash 2000 card has been installed can be tested to insure that the Flash 2000 card is working in that system.
Since some systems may have time-sensitive software, it is safest to run any date-testing programs from a clean boot (boot from a bootable diskette).
The text screens outputted by Y2KTEST.EXE are shown below. After starting the program, a screen appears explaining the program. After pressing Y to continue, the date is set to just before midnight on 12/31/99 and the RTC, BIOS, and DOS are tested to see what happens at the century change. The program can return three different results - the RTC rolls the date over correctly and no BIOS correction is needed, the RTC does not roll the date over correctly and the BIOS does not correct for it, or the RTC does not roll the date over correctly and the BIOS corrects for it. After installing the Flash 2000 card into a system that was previously reported as having an RTC that does not roll the date over correctly and a BIOS that does not correct for it, the Y2KTEST program should then report that the RTC does not roll the date over correctly and that the BIOS does correct for it.
There may be some systems with Y2K compliant clock chips which our Y2K test utility may indicate as having non-compliant clock chips. This is because some newer Y2K compliant clock chips may use a non-standard location for the century byte. It will be very rare that a PC motherboard will use a Y2K-compliant RTC. There is only one Y2K-compliant RTC that we know of which uses the standard location for the century byte. This is the Dallas DS12C887. This chip can be used as an upgrade on some motherboards and there are some new motherboards that are supplied with this chip. If a different type of Y2K compliant RTC is used which does not use the standard location for the century byte, this chip may still not provide Y2K-compliancy at the RTC level for applications or operating systems that access the RTC directly, since such programs may be assuming that the century byte is in the standard location.
Y2KTEST Revision 1.05 Copyright 1998 Micro Firmware, Inc. All rights reserved. Website: http://www.firmware.com/ Email: sales@firmware.com support@firmware.com Phone: 800-767-5465 or 405-321-8333This program will test the Real Time Clock Chip and the BIOS on this PC to determine whether it can successfully roll the date over from Dec 31, 1999 to Jan 01, 2000.
Note that it is expected that the Real Time Clock chip on almost all PCs will not roll the date over correctly. What is of more concern is whether the BIOS will correct for this hardware problem.
The date and time will be temporarily changed and will be changed back after the test. You may wish to check your date and time after running this test. Phoenix Technologies, Ltd. and Micro Firmware, Inc. assume no liability or responsibility for any harm this free program may cause. If you do not agree, please exit now by pressing N.
Press Y to continue or N to exit.
* The Real Time Clock chip on this PC does not successfully roll the date * * over from December 31, 1999 to January 01, 2000 * * * * The BIOS on this PC does not correct for the date rollover problem in * * the clock chip. *
The date and time were temporarily changed and were changed back after the test. You may wish to check your date and time to ensure that they were correctly restored. Phoenix Technologies, Ltd. and Micro Firmware, Inc. assume no liability or responsibility for any harm this free program may cause.
Copyright 1998 Micro Firmware, Inc. All rights reserved. Website: http://www.firmware.com/ Email: sales@firmware.com support@firmware.com Phone: 800-767-5465 or 405-321-8333
* The Real Time Clock chip on this PC does not successfully roll the date * * over from December 31, 1999 to January 01, 2000 * * * * The BIOS on this PC corrects for this problem so the date will * * successfully rollover to January 01, 2000. *
The date and time were temporarily changed and were changed back after the test. You may wish to check your date and time to ensure that they were correctly restored. Phoenix Technologies, Ltd. and Micro Firmware, Inc. assume no liability or responsibility for any harm this free program may cause.
Copyright 1998 Micro Firmware, Inc. All rights reserved. Website: http://www.firmware.com/ Email: sales@firmware.com support@firmware.com Phone: 800-767-5465 or 405-321-8333
* The Real Time Clock chip on this PC will successfully roll the date over * * from December 31, 1999 to January 01, 2000 and needs no correction in the * * BIOS. *
The date and time were temporarily changed and were changed back after the test. You may wish to check your date and time to ensure that they were correctly restored. Phoenix Technologies, Ltd. and Micro Firmware, Inc. assume no liability or responsibility for any harm this free program may cause.
Copyright 1998 Micro Firmware, Inc. All rights reserved. Website: http://www.firmware.com/ Email: sales@firmware.com support@firmware.com Phone: 800-767-5465 or 405-321-8333
In case it may be useful to anyone, the Y2KTEST program can return some errorlevel codes:
0 = RTC is compliant
2 = RTC is not compliant, BIOS is compliant
6 = RTC is not compliant, BIOS is not compliant
254 = user entered "No" when asked if wants to run test
255 = invalid command-line
Any PC can also be tested for the date rollover problem manually (without running a testing program). Boot clean to a DOS prompt. Using the DOS DATE command, set the date to 12/31/99, using the DOS TIME command, set the time to just before midnight (11:57pm). Power the system off, and then turn it back on after waiting long enough for the date to have advanced to 01/01/2000. On most PCs the date will then be found to be 01/04/1980. 01/01/1980 is where DOS starts calculating the date. DOS will usually set the date to 01/01/1980 if the date and time info is lost, such as when a battery is replaced. The reason for the 01/04/1980 has to do with diagnostic date codes used by DOS. If DOS finds an out-of-range date (year must be 1980-2099, month must be 1-12, day must be 1-31), the date will be set to 01/04/1980. Another example of the diagnostic date code is that an invalid BCD (binary coded decimal) code in the calendar registers of the clock chip will result in the date being set to 01/03/1980.
When performing a manual date rollover test, it may be necessary to disconnect a network cable from the system, as some networks will automatically synchronize the system time with the network server time on bootup. This may occur even when not logging onto the network. Also it may be necessary to disable the Daylight Savings Time adjustment feature in Windows 95. Otherwise, depending on the time of year in which the test is run, Windows may set the time back an hour after rebooting.
When performing the above manual testing in a system with a Y2K-compliant BIOS (or with a Flash 2000 card installed) and setting the date to test the century change with the system running, it may be observed that if the system is turned off and back on and CMOS setup is entered right away, the year may be indicated as 1900. This is because there has not yet been a BIOS call, which is what causes the Y2K-compliant BIOS to correct the century byte in the clock chip. This does not mean that the BIOS is not correcting the date as far as any programs that may get the date from the BIOS are concerned. To test for this, the following DEBUG script can be run. This DEBUG script makes a BIOS call to ask the BIOS what date it is.
C:\>DEBUG (type DEBUG at DOS prompt) -R AX (enter command at dash prompt) :0400 (enter this value at colon prompt) -E 100 CD 1A CC (enter command at dash prompt) -G=100 (enter command at dash prompt)AX=0000 BX=0000 CX=2000 DX=0101
Ignore the above register dump except for the
contents of CX (year) and DX (month/day)-Q (type Q at dash prompt to return to DOS prompt)
Some Award BIOSes will not accept any date with a year outside the range of 94-99. The BIOS apparently checks the date during POST on each boot and resets the year value if it is not in the range 94-99. It will normally be reset to 1994 or 2094 (the century value is left unchanged). If powered off over the century change, the date will probably be set to 01-01-1994 on the first boot in the year 2000.
This problem is not corrected by the Flash 2000 card, although the Y2KTEST program will erroneously report that the BIOS is Y2K compliant after the Flash 2000 card is installed.
This problem can be corrected by a BIOS upgrade (if one is available) or by resetting the date every day. Actually, just setting the date on each boot is sufficient - the system should maintain the correct date as long as it is left on. One way to deal with this problem is to just leave the system on, and set the date anytime the system is rebooted. It could also be helpful to put the DATE command on a line in the AUTOEXEC.BAT file, so the date will have to be checked and set on every boot.
A BIOS upgrade will need to be obtained from the motherboard manufacturer (or possibly from a third party).
Here is a URL to website with some information on how to identify the motherboard manufacturer from the Award BIOS version. Contact info for many manufacturers is also given here. The manufacturer can then be contacted to ask if a BIOS upgrade is available.
http://www.ping.be/bios/numbers.shtml
To test for the type of BIOS discussed above, set the date to 01-01-2000 (or any date in the year 2000) and reboot the system. A BIOS with the problem discussed above will have set the date to 01-01-2094, with or without a Flash 2000 card installed.
Phoenix Technologies, Inc. purchased Award in 1998. In early 1999, the contents of Award's website was integrated into Phoenix's website, which resulted in the loss of some links to Award's site which were given in previous revisions of this document and in the printed documentation we supply with the Flash 2000 card.
In the Y2K FAQ on Phoenix's site, they state that work is being done to develop a software fix for the Award BIOSes with the problem described above. Here is a link to the Phoenix Y2K FAQ:
http://www.phoenix.com/support/y2k.html
Many recent Award BIOSes will fail our Y2KTEST utility and various other Y2K test programs, but will show the correct date when doing a manual DOS date rollover test.
Award stated on their website that this is only an issue with passing the test utilities, and that the BIOS is actually Y2K-compliant. Since there is no "official" specification for Y2K-compliancy, these BIOSes could be said to be Y2K-compliant, however, they are less "compliant" than other BIOSes that correct for the Y2K date rollover problem. These Award BIOSes will check the date on each boot to see if the century needs to be corrected. This is why they will roll the date over correctly in a manual DOS test. Other modern BIOSes will correct the century anytime a BIOS call to get or set the date is made. So if a system with this type of Award BIOS is left on during the century change, any program that makes a BIOS call to get the date will get the wrong date until the system is rebooted.
This problem was corrected by Award in November of 1996, but there may be Award BIOSes with later dates that show this problem. BIOS updates to correct this problem may be available from the motherboard manufacturer. The Flash 2000 card can be used to correct for this problem.
That depends on what is meant by compliant. On most PCs, a Y2K-compliant BIOS (which may have been provided on the system, or accomplished by a BIOS upgrade or by installing a card such as the Flash 2000) will cause the date to roll over correctly. For most users, this solves the Year 2000 problem. But for a system to be declared completely "Year 2000 Compliant", it should have a compliant clock chip. This is because there may be programs that access the clock chip directly for the date and time. Such programs are not common and would normally be found in industrial, military, or big business environments where specialized, custom-made applications are used. Such programs could also be considered non-compliant since they are depending on the RTC to roll the date over correctly when it is known that the RTCs in almost all PCs will not. Some operating systems, including some versions of Unix, may access the clock chip directly. Such OSes may account for this problem in current revisons or have fixes available. The Flash 2000 card or a Y2K-compliant BIOS will not solve the Y2K problem for OSes that access the RTC directly.
It is possible to upgrade the clock chip in many PCs to a Y2K compliant chip. Dallas makes a chip called the 12C887, which can be used to replace 12887 and 12887A and compatible chips and in most cases can replace the 1287 and 1287A chips. This was released in December of 1997 and can be obtained through a company called Resource 800. A URL for their web site appears below. Their phone number is 800-430-7030. Although most computer users will not need to be concerned with replacing the clock chip, this issue may need to be taken into account in cases where there is some government or corporate regulation that needs to be met. Note that this will not be an option for most PCs, since the clock chip is often soldered onto the board or it may be a surface-mount chip or it may be integrated into the motherboard's main chipset.
Also, for a system to be declared completely "Year 2000 Compliant", all software installed on that system must be compliant. All kinds of applications may have various problems with dates beyond 12/31/99. These problems are solved only by updating the software and can not be solved by the clock chip or the BIOS or any similar solution such as the Flash 2000 card.
We have had some inquiries regarding "time dilation". Time dilation is actually the name of a theory that Einstein came up with that has to do with time slowing down due to motion. There is a web site or two devoted to a problem involving the time and date randomly leaping ahead on PCs after 01/01/2000. This was first referred to as time dilaton, later renamed to the Crouch/Echlin effect, and sometimes called "time-leap". They say that this occurs on 286, 386, 486, and Pentium systems. They seem to have narrowed this down to systems that have unbuffered clock chips. There are references to test utilities but none seem to be available. No information is given as to what clock chips are in the systems tested. No information is given as to what type or version of BIOS is in any system tested. No information is given as to what brand or model of systems have been tested.
Based on our own knowledge and consultation with a trusted authority, we think that what is being seen here is that some older systems may have broken BIOSes that do not follow correct procedures for getting data from the RTC, which may cause this type of a problem on systems which also have a non-buffered clock chip. (The Motorola 146818 and compatilble RTCs used in the original IBM AT are unbuffered as are many RTCs built in to chipsets. All Dallas RTCs are buffered). It should follow that any such system would have the same problem both before and after the century change. We would then conclude that this is just another of the thousands of very specific bugs that can be found on specific hardware and that this is not a Y2K issue.
Although we would tend to think that this is a "non-issue" (at least for most people), it is possible that there is more to this. Perhaps more information on this subject will be forthcoming in the future.
Here are links to a couple of documents from Intel, in which they say they have thoroughly investigated all proposed theories and have found no evidence of the existence of the Crouch-Echlin Effect:
http://www.intel.com/support/year2000/c-e-wp.htm (Overview)
ftp://download.intel.com/support/year2000/ceeffect.pdf (White paper)
Here are links to Crouch and Echlin's web sites:
http://www.intranet.ca/~mike.echlin/bestif/ (Mike Echlin)
http://www.nethawk.com/~jcrouch/dilation.htm (Jace Crouch)
And links to a couple of interesting articles:
http://www.y2ktimebomb.com/Computech/Issues/hsmith9845.htm
http://www.y2ktimebomb.com/Special/Opinion/Readers/hsmith9847.htm
http://www.year2000.com (Lots of info including FAQ and many links)
http://www.rightime.com (Detailed PC-related technical info)
http://www.dell.com/r&d/vectors/vect_1-3/v1-3_century.htm
http://www.dell.com/r&d/whitepapers/y2k/y2k.htm
(Excellent articles from Dell on RTC/BIOS/Y2K)
http://www.mitre.org/research/y2k/ (Non-profit engineering group)
http://www.resource800.com (Source for Dallas 12C887 chips)
http://www.nstl.com (National Software Testing Labs - YMARK test)
http://www.microsoft.com/year2000/ (Microsoft FAQ and Product Guide)
http://www.pcy2000.org/ (PC Y2000 Alliance)
http://www.ionet.net/~tslade/y2klinks.htm (huge collection of links)