NOTE: This is all based on just my reading and thinking, except as indicated; I have only one PC that can reasonably be tested, and it has not shown the effect (yet).
NOTE: No significant reports of the phenomenon have been seen in and after the Year 2000.
2007-01-21 : Some dead links are now underlined.
The topic has gone rather quiet lately (end June 1999) : it does seem that the originators must have seen something; but it's surprising that there are so few trustworthy reports of it.
It seems that sometimes, when the year which is set exceeds 1999, the "CMOS" time/date reading from the Real-Time Clock (RTC - it runs even when the PC is off) in some MS-DOS/Windows PCs can jump at turn-on; this is generally called Time Dilation (often mis-spelt). Presumably, this will be possible not only in "desk" PCs, but also in any other sufficiently similar system, including embedded controllers. Time Dilation will depend on RTC type, PC type, BIOS, etc. Additionally, (less often) other parts of the chip, the CMOS RAM, may be corrupted. I hear that *some* machines just won't boot.
Some people just plain deny the existence of Time Dilation; and there appears to be no clear agreement among the rest as to the mechanism and circumstances. Many reports give inadequate details, in particular of frequency of occurrence and of whether the error is "sticky". I have not observed it myself, but have few machines to test.
Jace Crouch wrote : The official name is the Crouch-Echlin Effect (Dave E. coined that one), but mostly we call it TD, for "Time and Date Instabilities," or CE/TD as an abbreviation.
TD is logically independent of the 1999→2000 transition.
It has been said - and by others denied - that after 1999, a booting PC's BIOS should do more date work and can mis-handle the RTC, getting the wrong date-time and maybe storing an error back. This should only occur if RTC access and RTC update (each second) coincide. It has been remarked that a y2k-oblivious system should therefore not suffer TD; DdL responded "all the Toshiba T1200s I've looked at (a) *are* compliant (by usual criteria) and (b) display TD".
As far as I know, there is nothing actually wrong with the RTC as designed; it handles a 2-digit year and rolls properly from 99 to 00 (the "century" is, by later convention, stored in the associated CMOS RAM). But the user of the traditional unbuffered RTC product must be more careful than the BIOS authors were to handle it correctly. For 1984 µs in every second, the RTC is updating, and must not be read or written. BIOS logic is intended to take care of this, but the care fails from 2000 because date calculations take longer. This seems a reliable statement; but it is second-hand - I have made no tests myself.
I gather that the problem is not seen in machines with buffered RTCs, where (I suppose) the specification allows access to the data at all times.
:Dave (1999-01-07) :
Intel's report of its investigations into Time Dilation can be found at ... ;
--bks (1999-08-03) : Obsolete URL. Now
lbza3a
and
lbza3b; - seemingly now removed.
1999-04-08 : another description of TD, by Cochrane Research Ltd. However, I disagree strongly with the present Sec 8.1.2, 02h & 04h access the RTC.
DE, 1999-12-18, in uty2k :-
New material from Jace on http://www.nethawk.com/~jcrouch/dilation.htm
"We have also received numerous reports of TD-like time and date
instabilities in Y2k on process control systems, on ATMs, on bar-code
readers, on refrigeration equipment, and other instruments and embedded
systems".
Quote :- "Linux reads the time directly from the realtime clock on boot, bypassing BIOS routines". But does it stop them? If not, while there may be no fear of plain TD, how about CMOS corruption?
Suggestions that the TD error is due to the RTC chip getting set into maintenance mode, 8x rate, were made; but are now authoritatively denied.
A well-known design flaw in most versions of MS-DOS means that if a PC is left running over two or more midnights, without a MS-DOS date/time function being used in between, then only the first midnight will be seen. The RTC is correct, but not consulted. At a reboot, the RTC will be read, and the date will be right. Any report of days missed is a dubious TD case.
If TD occurs, the CMOS memory may also be corrupted. Have a written backup of the setup screens, and/or a restoreable backup on bootable floppy of the CMOS RAM contents. The HDD boot sector may also be, or appear to be, corrupted.
It is reported that the boot sector of the HDD may get corrupted. However, CMOS data is used to set up HDD access, so HDD read/write problems may merely be consequential; I do not know.
It has been suggested that a weak or dying CMOS retention battery may be involved.
But, supposedly, the first effect of a weak battery should be that the clock oscillator does not run, well before setup data is lost.
The RTC will, of course, be tested during Power-On Self-Test, as well as being accessed for data by the BIOS. Could it be that mere bad data comes from BIOS read-access failure, whereas permanent corruption comes from POST activity?
2000-01-01 must be a tempting date to use for a virus trigger, and the virus might simulate TD or other Y2k problems.
For the history of TD, see for example the FAQ by Dave Eastabrook, Elmbronze Ltd, Year 2000 Consultant.
On Fri, 07 Aug 1998, Jace Crouch wrote in news:uk.tech.y2k :-
As some of you are aware, Mick Echlin and myself have been putting in a great deal of work this past year on the time and date instabilities that will affect certain computers and embedded systems in y2k. Now that we are at T-minus 511 days before the compost hits the Cuisinart, it is time to share some results :-
How TD Occurs on Personal Computers;
My main TD web site;
Mike Echlin's main TD web site; also this.
And for people who missed the beginning of all this last August - note that this URL points to a 150K+ text file.Mike and myself be posting more pages to our websites over the next couple of weeks, before and after T-minus 500 days. I'll post URLs and updates as these materials become available.
And now (1998-09-15) Echlin's tdpaper; and (1998-11-19) :-
And 'Jace Crouch's Theory of Why "Time Dilation" Occurs', dated 1998-12-12.
Dave Eastabrook of Elmbronze Ltd is now supplier of TD Tools, the Echlin and Crouch product, in Europe and elsewhere - see info at www.elmbronze.co.uk or www.elmbronze.com (backup site is at TD).
The following was taken from his then newish Sig on 1998-12-01 (it changes so often that I cannot always keep up - see uty2k/csy2k for some of the latest) :-
Dave Eastabrook; Sales & technical director for TD Tools; Europe, ME & Africa. Combat Time Dilation, the Crouch-Echlin Effect, on your PC, year 2000 & after. GBP24 (+VAT in E.U.) http://www.elmbronze.co.uk or http://www.elmbronze.com Contingency site: <URL:http://www.elmbronze.demon.co.uk/products/TDsales.htm>.
The product is/was also resold by Compaq/Digital. The product has NOT been tested by me. I believe that basically it tests whether the RTC is unbuffered. Euro-pricing is available, I see.
1999-04-03 : a new improved version, Release 2.0 of TD Tools, is available for *free* download, without registration or follow-up.
1999-09-19 : A new test and fix may appear soon?
See also Kennedy Software & Systems Ltd.
There is/was a problem, involving the RTC, with the Intel 810 chip set for Celeron-based PCs. It appears that the RTC may be read while invalid. The fix is a (pre-production?) BIOS update.
1998-12-08,09 : To my surprise, on the only PC that I am willing and able to test, altering $40:$6E in RAM with DEBUG and then resetting the date from the DOS prompt alters the TIME in the RTC too, as shown by warm or cold reboot. Also, using Int 21/2B to set the date sets the RTC time, but Int 1A/05 does not. The finger thus points at Microsoft DOS 6.20.
I believe that the position is symmetrical, that altering the time with MS-DOS also sets the RTC date.
ISTM that any unsuspected alteration of the RTC, whether or not of significance in itself, might confuse TD investigations.
The double setting is not of itself unreasonable; but it is not documented where it should be.
1998-12-21 : I think that I have now conclusively proved it with a test program, and I am told that it can be seen by inspection of the code in several versions of MS-DOS (details are now in Year 2000 Programming).
1998-12-28 : See there also re Windows Control Panel Date/Time. Fiddling here changes MS-DOS & RTC settings, even without using OK.
The potential of these effects for confusing testers should be clear.
Be very careful of the adverse consequences of time occurring in the wrong order.
I have no prospect of being able to do any original hardware research on the subject; I have no facilities, and no PC that I'd be willing to risk. My interest has come through a general interest in computers including PCs, which I used to use integrated in measurement work, and a non-professional interest in some aspects of time. Because of the former, I do know a bit about computer architecture in general, and the RTC area in particular.
All I can do, therefore, is to help spread such news as seems sufficiently trustworthy, and to inject the occasional thought based on general experience.
Please do not send me any commercially-confidential technical details; I have only been accustomed to working openly, and I don't want to have to remember what not to say.
I recall about six reported Y2k problems with the PC; 1 & 2 are irrelevant to the discussion of TD, 3 is trivial to fix, 4 is very annoying unfixed, 5 & 6 are worse :-
ISTM that a supplier must state very clearly indeed which of these a product tackles.
The following sections basically report hypotheses; the only testing I've done is clearly indicated.
On 1998-07-15, I noted a *possible* potential race hazard in the circuit of the 146818 RTC as shown on Fig 12 of the RS data sheet - if the bistable that senses 68xx/808x starts wrong, then on the *first* access after power-up there **could** be runt error-pulses on the Enable lines. Now if the memory is fast enough, a duff write is *possible*. OTOH, the first access should be an address write to Port 070h... I don't expect it could be significant, but it might be; does anyone know if it has been mentioned? It is not, however, the cause of standard Time Dilation.
I've not, AFAIR, read that the internal mechanism for TD-associated CMOS corruption was known.
The stated mechanism for plain TD is that the RTC is perturbed by being addressed during its update cycle; if the RTC is read, the data may/will be incorrect. Remember that to read the time/date, it is necessary to write the sub-address to 070h. Now if there is an attempt to write (internal/external source), this could conceivably lead to an internal "bus fight" where one bit of CMOS logic is asserting "0" and another "1" on the same internal line(s).
On 1998-10-11, I had a simple thought; perhaps the internal mechanism of CMOS corruption is just that the internal address and data buses are being used by both internal and external sources, and are therefore not being driven to the proper values, leading to wrong numbers being written in the right place, right numbers in the wrong place, and wrong numbers in the wrong place?
On 1998-10-07, I had an earlier thought; a bus fight will draw substantially increased current from Vcc, because of the nature of CMOS logic. Internal impedances are likely to prevent this overcurrent from being physically destructive. However, the current may cause a sudden drop if the internal Vcc, particularly as the Vcc supply may be (I think) multi- sourced from battery and PSU through diodes and otherwise comes from the low-current battery. The drop may or may not be detectable on the external Vcc pin.
If the CMOS RAM is exposed to sudden changes in internal Vcc, especially at a time when other parts of the chip are active (some improperly), it may have every excuse for making errors in memory; this need not require a drop from full Vcc to the minimum sustaining voltage.
Just a theory, which I have no possibility of testing; but it could be worth a lab trying to monitor the Vcc line at the pin of the RTC chip.
1998-11-13 :- A thought has suddenly occurred. Do we actually know that all BIOSes use the UIP flag???
Obviously some heed must be paid to Update timing, for otherwise bad data would occur 0.025% of the time both before and after Y2k.
But the data sheet says that there are THREE ways to avoid Update :-
Now it seems tempting to use the PF bit of the PI system, or the PI itself, since the PI can be set to >>1 Hz to make the system boot faster (this is near-false logic, but who is to say that the BIOS writer did not think it?); and Update Warning appears guaranteed to start halfway between PF rises (fig. 14 is rather small).
Perhaps TD occurs in systems with (a) an unbuffered RTC and (b) a bold BIOS which (i) uses PI flag timing set too fast for YYYY>1999 and (ii) takes longer to read after 1999 and/or always writes if CC=20?
Conclusion 1998-11-21 (after raising the point here and elsewhere) : however, the general belief appears to be that only UIP is used, never PI.
1999-01-24 : Either TD depends on the actual turning-on of the power to the system, or it does not (thought : the RTC changes from battery power to system power at turn-on & vice versa; a shoddy board, or one with a defective but necessary capacitor, might not do this well, and could upset the RTC).
1999-01-20 : Until I received E-mail from Tom Becker, of The RighTime Company, Miami, today, I believed that the RTC Update Time was 248 µs. However, with a 32 kHz clock, which is used in the PC, the Update Time is 1984 µs. This affects estimates of the probability of TD. Please correct any erroneous impressions that you may have obtained.
1999-01-28 : TD is a century-dependent problem, in that it occurs only when the date set is in 2000 or higher; this is the fundamental original observation. I don't recall reports of tests in 2080..2099. It seems possible that the root cause is not that CC=20, but that YY<80 and the system therefore decides to ensure that CC=20.
1999-01-30 : AFAICS, there are exactly four mutually exclusive possibilities for pure "classical" TD :-
I think no-one now believes #3; there is reported evidence against #0.
The usual observations lump together #1 and #2, which is undesirable, because :-
Moreover, the general belief is that #1 is innocent.
Therefore, testing should concentrate on #2 without #1 (and, if possible, #1 without #2).
Fortunately, this is easy - the PC merely needs to be HARD-rebooted, fully, by software. AIUI, on all standard PCs (AT+?), the following, executed when the keyboard controller input buffer is not full, will generate an electrical signal equivalent to that of a physical RESET button, driving the CPU reset line and releasing it as at power-on. See TSFAQP #49 for details; Ralf Brown's List supports.
mov al,0FEh ; out 64h,al ; HLT
HLT added 1999-02-06; covers the possibility that undesirable instructions might be executed before the reset signal takes effect. Also, it *may* be necessary to reset the PCI hardware.
The full POST, including the initial RAM test, will be done (and, the monitor being already warm, the RAM test should be visible on most machines). A one-line DEBUG script of just o064 FE will do the reboot using
DEBUG < reboot.scr
and this can be put at the end of a DILATION.BAT called at the end of AUTOEXEC.BAT. The reboot process should be so regular that any significant TD will be noticeable. If DILATION.BAT contains
@echo.|date @echo.|time @echo. @echo.|date >> dilation.log @echo.|time >> dilation.log @echo. >> dilation.log
then the screen and the disc will show what has happened; the rebooting should be regular enough that any TD over a few seconds will show, and a simple program can analyse the log for irregularities.
Actually, I'd call something derived from components of my program int_test.pas so that the log could include Daycount and Day's-Ticks, for ease of inspection.
P.S. 1999-03-31 - this function is now included in int_test.pas (*.pas and *.exe are in programs/); as far as I can see without an affected PC, it should detect actual TD.
The general belief is that true TD depends on the date in the RTC being after 1999 (CC=20 or YY<80), but not otherwise on the date or time. On that assumption, the reboot above can be preceded with, say,
@date 2001-2-3 (locally formatted) @time 04:05:06
and then the log readings should be all the same date, all nearly the same time, and trendless; anomalies will be relatively visible.
That, of course, tests the whole of #2 en bloc - from the start of POST (AIUI, nothing programmed precedes that) to execution of AUTOEXEC.BAT. It should be possible to call a DILATION.COM/EXE early in CONFIG.SYS, and let its initialisation part do the work. With the resources of a good programming lab, it should be possible to code the taking of the readings for logging into an Extension Boot ROM, with output possibly direct to ASCII printer - this would discriminate between before and after its execution, pointing the finger towards either POST or MS-DOS.
1999-02-03 : Although I don't know fully how, it is possible to compile/assemble a short program and load it into the boot sector of a floppy. Such a program could load a COM-format file into RAM, and jump to it. This would allow the full use of PC tools in writing the program, while not using any other software in its execution - just the PC firmware before execution.
IMPORTANT : I cannot see that any of this would damage the PC; and I have tried the individual components above on the 486dx33. But I have not run the whole loop intensively, and have no PC I can safely spare for test. I can accept no responsibility for any damage caused by attempting any of the above.
1999-02-01 : I fear that some reports of alleged TD are reports of other, well-known, effects (such as MS-DOS losing days when running untouched past more than one midnight); and many are just not detailed or reliable. I'd like to see statements that a specific identifiable (identified?) machine was booted N times over T days, executing such-&-such software, with M instances of TD changes (and whether or not persistent over next boot), this giving an incidence rate of M/N ± X (95% confidence), and that the distribution of errors was consistent with random to Z confidence, and that the exact nature of the errors was such-and-such.
1999-02-01 : If TD occurs, obviously it can be noticed while running Windows; but IMHO any reported tests need to be without Windows or applications, and with minimal DOS. Preferably with varied (or no) DOS. H'mmmm ... with a MS-DOS dating from PC-XT days, that does not know of the RTC, on the assumption that we may be looking at pre-software firmware.
1999-02-24 : It occurs to me to remark that most TD testing has been done on "Machines" where a machine consists of a particular set of hardware, firmware, and software; and that it has been shown that the only software needed to show the fault is DOS (am I right?); and that the DOS used will naturally be that found on the hard disc.
But most PCs can be booted from floppy; and, if one is only using the fundamental facilities, from any boot floppy.
So, given a PC showing TD, I'd generate a boot floppy (SYS command), and test booting from that. I'd expect the same TD; but if it is different, that's clearly significant. Then I'd test with boot floppies carrying other generations of DOS. One might imagine that all versions of DOS since the introduction of the RTC should be equivalent; but, if otherwise, that is significant. Booting from a definitely pre-RTC DOS floppy is surely not equivalent; the OS and its calls will be RTC- unaware, but a program such as int_test can still observe the RTC.
Perhaps this, or something equivalent, has been done; if so, it would be nice to have the test available so that it can be applied to any machine.
1999-03-31 : Some systems may record new information in the CMOS RAM at each boot; my Amstrad PPC640 records the date/time of last use (not last boot; end-of-use), and reports it at the next boot. It is possible that TD is caused by error in this stage; it would explain why it is only seen in some systems.