Time Dilation

TD - (Time Dilation / Time/Date Jumps)

Introduction	Our Involvement / Background ?
Truth - Facts / Opinions	TD & Y2K
Tests / Proof	TD Identify
TD Fix

Introduction ?:

If you're not already familiar with TD, this page won't make much sense to you !. Sorry!.

Here, I'm presenting only some views on this issue, some facts, some test results, etc. TD has been controversial; I'm mainly trying to clarify some TD issues. You're welcome to disagree with opinions expressed here; but, where possible, technical facts should be used as the bases of opinions. And, I hope that my definition of "TD" (ie, Date/Time jumps in PCs, at boot, and possibly subsequently) is sufficiently close to the "standard" definitions.

For good background info, and views from the people (Jace Crouch and Mike Echlin) who "identified" TD in 1997, experimented with it, etc, you must check their web sites. Also, the content at these sites is evolving, and so you should review the details there on a regular basis, in my opinion.

Compaq performed some initial TD tests, sometime in mid/late '98 (I don't recall the dates), and indicated that TD existed. Compaq then made some arrangements to market and/or recommend some TD software from the Crouch-Echlin team. (There are still some references on the web to these arrangements - corrections welcome!).

Then, Intel and Compaq made additional fresh TD studies, and published detailed (final ?) findings. Basically, they concluded that TD could exist, but does not - but, you should read their full reports, or download a PDF copy from here. The Intel report is well structured, and includes substantial accurate relevant technical data. (You'll notice some trivial typos, etc, but the intent is clear). What's most interesting (IMO) regarding the Intel comment that they never noticed TD, is that they seem to have subsequently created something like TD in one of their own products, and had to issue a BIOS fix to overcome the problem. I haven't much info on this saga, but check out some references.

There are many other web sites with TD references. Try some Searches!. If you know of any good ones, please let us know - we'll include them here. However, beware!. We've seen some sites which merely copy TD-data from other sites - sometimes without acknowledgements - which could be flattering, or theft... But, sometimes the original data (which is copied) is technically incorrect, or unproved, etc. This activity has a few consequences, including:
- it indicates that the copier doesn't understand the issue,
- casual observers might believe something that's repeated at multiple sites.
Beware !!!. Some TD sites, commentaries, products, etc, are totally speculative; some seem to be based exclusively on the findings of "others"; some are totally inaccurate, etc. Be cautious !.

Mr. Harlan Smith, now regrettably deceased, played a very significant part in investigating, highlighting and documenting many Y2K and TD issues. For some of his concise comments on TD, visit here or here.

We would hope that the overall TD issue can be finally resolved, and hope that the contributions here will lead towards that end, rather than trigger additional controversy!.

Our Involvement / Background ?:

I became interested in this matter from the very beginning (1997) of the public discussions, and keenly watched the developments up until late '98, and indeed communicated with some of the main TD people. However, by that time, when it seemed that TD was still a technical "mystery", with numerous theories, speculation, etc, and no rigid proof, I also did some investigation into TD. I continued to closely watch the Intel/Compaq studies and findings, and reports from Tom Becker and others, and compliment them on their major efforts.

To pre-empt the question: I'm a qualified electronics engineer, but have spent most of my career (30 years) in software development - perhaps 5% in hardware (digital electronics, I-O interfaces, CPU cards, comms, etc), and the 95% in software (numerous assemblers, OS development, microcomputer systems, microprocessors, some BIOS software, and hi-level apps (commercial, industrial, scientific), etc). Rightly or wrongly, I believed that the TD issue had to have specific technical bases, should be fully provable, and should leave no room for speculation. And, so, I got more involved...

The Truth on TD - Facts / Opinions:

In my opinion, Intel's report is very accurate and very thorough. But, marginally incomplete. (One wonders why the report is "incomplete" - maybe they didn't try to create TD; maybe they had no wish to offend BIOS manufacturers; maybe..... ?).

TD does exist.

To clarify, my initial findings and explanations differed from the TD people, and from Intel. I concluded that:
    - TD exists
    - There is only a single cause for TD, namely poor BIOS code
    - TD can be easily demonstrated (contrary to Intel's findings)
    - PCs with a potential for TD can be identified
    - TD can be easily fixed
    - TD is NOT usually Y2K related (though it can be in rare circumstances)
    - TD is NOT dependent on the BIOS "Path" (unless the BIOS code is very poor)
    - TD has been around since the initial IBM PC-AT of 1984
    - The poor BIOS code which leads to TD is still common today
    - As the speeds of PCs increase, the probability of TD decreases
    - RTC buffering cloaks TD (where present); the probability of TD decreases very significantly
    - TD can arise at BOOT time, as already claimed/observed
    - TD can also arise whenever any PC software issues RTC-commands to retrieve the Date/Time
    - Other factors also influence the probability of TD (higher in "Busy" PCs, etc).

Here's a simple "test" you should try: approach your PC users, especially users of older PCs (286/386/486) and users who've been using the PCs for some years. Ask if they ever observed unexplained incorrect dates/times when they powered on the system, or indeed, subsequently ?. Simple test, eh ?.

"Poor BIOS code" is where the code accesses the RTC, but does not conform to the RTC specs. These specs can be breached in many ways - not checking UIP correctly, not checking UIP at the correct times, not guaranteeing that accesses will complete within specific times; not enabling and/or not disabling other PC activities at the correct times; etc, etc.

In general, TD occurs very rarely:
- If the BIOS code in a PC is correct, then it will never occur in that PC.
- If the BIOS code has RTC "holes", then it may occur. It is not possible to predict when it might strike in these PCs, nor at what frequency: there are too many variables, as indicated above. And, if the RTC is buffered, (ie, an additional buffer/latch), the probability is greatly reduced, though technically, still not zero !.

In the following sections, I'll briefly touch on some of the above opinions... If you'd like further details to be included here, let me know. Most of the above observations, opinions, facts, should be considered in light of the Crouch-Echlin and Intel commentaries.

TD and Y2K:

TD, in general, is not related to Y2K, because most of the BIOS "holes" I've seen are not Y2K related. This contradicts the Crouch-Echlin findings. They continue to say that all their observations occur only with 20xx dates, and that the frequency of TD will increase on/after 01/01/2000. I don't agree - in general. (One possible explanation for the C-E theory/findings is that they saw only Date jumps, and that in all cases, the date jumped to 20xx. With most of the DATE jumps in my tests, the year did indeed jump up to 20xx, but that was just the result of some calculations in the PC, and was not related to the actual date of the PC. In any case, "Time will tell" - unless "time" itself exhibits TD !. If the incidence of TD significantly increases after 01/01/2000, then I'm wrong.

[PS: The ideas on this web page were submitted to CIS and to various NGs in late '98 and throughout '99, and this web page was composed in early '99. As of the time of writing this PS (April 2000), I've closely watched the technical Y2K NGs throughout the Y2K changeover, and have seen just ONE lonely reference to TD, with some speculation that it might be related to Y2K. Time/Date errors were observed on a single old 386, which was very rarely switched on. There was no proof that the problems were Y2K related. I've seen almost NO recent discussion of TD anywhere. And I recently visited one of the main TD sites, and noticed that the Y2K countdown clock there was still running (perhaps a few lines of Java). Not only is the Y2K clock still showing, but the behaviour of the clock reveals screwed-up software logic on how a countdown should be implemented - some values are decreasing, some increasing. And this from TD experts ?. Conclusions - as of April 2000 - you choose... incompetent; brilliant; scam; the fat lady didn't sing yet... End of PS]

However, there is a relationship between TD and Y2K, in some instances: Poor BIOS code (related to date handling), usually applies without any dependency on the century value (19/20).
- In all PCs without "century correcting BIOS code", which covers all PCs up to about '96/'97, and very many since then, then a century-dependency cannot apply, and the TD errors cannot be Y2K-related.
- In PCs with "century correcting BIOS code", then poor date-handling could occur in the non-correcting code, and/or in the correcting code. If the BIOS code has flaws only in the non-correcting code, then TD probabilities will not depend on century values. If the BIOS code has flaws in the new correcting code (irrespective of flaws in the non-correcting code), then TD probabilities may depend on century values. In the latter case, flaws may exist only when the century is 19 (in which case TD will occur only in 19xx), or flaws may exist only when the century is 20 (in which case TD will occur only in 20xx), or flaws may exist without reference to the century value (in which case the TD probability is not century-dependent).

..... whew..... wanna read that previous paragraph again ?.....

And, I've seen different BIOSes which fall into each of the above categories !. Therefore, TD is somewhat century dependent - though in some BIOSes, TD probability might be higher only in 19xx, and in others, it's higher in 20xx. Generally, however, TD is not Y2K dependent.

TD Tests / Proof:

To get at some technical facts, I wrote some test-code to illustrate TD. This code consists of two programs:
   - A TSR program which makes the PC very "busy", so that TD might occur more frequently than once every few weeks (!), and therefore be readily "observable". Apart from making the PC "busy" (hopefully in a "smart" way <wink>), this code does not otherwise intentionally "interfere" with the operation of the PC in any other way.
   - A small standard program which just asks for the DOS Date/Time (Int-21h), and the RTC Date/Time (through the BIOS, Int-1Ah), and highlights any "Jumps" in the returned values.

The programs use just standard DOS and BIOS facilities. They do not break any "rules" (unless via unintentional bugs !!). They do not read the Date/Time directly from the RTC. These test programs are not for sale, nor shareware, freeware, etc. (And, in the absence of such code being publicly available, you are, of course, entitled to totally ignore these notes and findings !).

Here's a small sample of a test run on a "real" IBM AT, using MS-DOS 5.0 (version is irrelevant). The actual test results contain much additional trace/diags data, so I'm just showing some relevant data here. Dates are MM-DD-YYYY:

    DOS:05-08-1999 14:25:16 RTC:05-08-1999 14:25:16 START !
    DOS:05-08-1999 14:58:37 RTC:65-65-2065 14:59:32 RTC JUMP ?
    DOS:05-08-1999 14:58:38 RTC:05-08-1999 14:59:33 RTC JUMP ?
    DOS:05-08-1999 14:59:11 RTC:65-65-2065 15:00:07 RTC JUMP ?
    DOS:05-08-1999 14:59:11 RTC:05-08-1999 15:00:08 RTC JUMP ?
    DOS:05-08-1999 16:31:00 RTC:65-65-2065 16:34:28 RTC JUMP ?
    DOS:05-08-1999 16:31:01 RTC:05-08-1999 16:34:29 RTC JUMP ?
    DOS:05-08-1999 16:35:04 RTC:05-08-1999 65:65:65 RTC JUMP ?
    DOS:05-08-1999 16:35:05 RTC:05-08-1999 16:38:40 RTC JUMP ?
    DOS:05-08-1999 16:45:51 RTC:65-65-2065 16:49:44 RTC JUMP ?
    DOS:05-08-1999 16:45:52 RTC:05-08-1999 16:49:45 RTC JUMP ?
    DOS:05-08-1999 18:09:49 RTC:05-08-1999 65:65:65 RTC JUMP ?
    DOS:05-08-1999 18:09:50 RTC:05-08-1999 18:16:02 RTC JUMP ?
    DOS:05-08-1999 18:54:44 RTC:65-65-2065 19:02:10 RTC JUMP ?
    DOS:05-08-1999 18:54:44 RTC:05-08-1999 19:02:11 RTC JUMP ?

Notice that the RTC yields invalid DATEs or TIMES (where underlined), sometimes. If DOS were to get invalid results on one of these RTC reads, (eg, at Boot), then the DOS Date/Time would appear to "Jump".

The "20" century showing in the "Date Jump" readings is caused by the way I handle the invalid dates in the display routines. It's not coming from the RTC, nor from the BIOS. The exact cause is as follows: If I get an invalid YY reading, such as FFh, I run this through a BCD-to-BIN function, which calculates 15 and 15, and delivers a binary/decimal value of 15*10 + 15 = 165. This is added to the century value of "19", yielding 2065, as displayed. This BCD-to-BIN function also explains values like 50 (F0), 00 (A0), 65 (FF), etc, in the DD, MO, HH, MI, SS values, where the code displays only the lower 2 digits. I have not checked how the BCD-to-BIN functions in DOS/CLOCK$ operate on invalid values - they might yield the same results as my code, or different results - all depends on how the programmer intended to process "invalid" values. If the DOS/CLOCK$ BCDtoBIN functions are similar to mine, it might explain why the E-C people saw only 20xx TD errors!!

...... hmmmm..... didn't think you'd want to read that para again.....

TD Identify:

I have experimented with some test-code (using two separate approaches) to identify PCs with poor RTC-based BIOS code. This code also establishes if there is any Y2K dependency, RTC-double-buffering, etc. If there is interest in this software, this could be "packaged" and released. Freeware ?. Shareware ?. Any views ?.

TD Fix ?:

Based on the above details, and especially on the "tests", I have written some code to "fix" TD, both at BOOT, and at any time subsequently. This is a DOS Driver / TSR.

Other software suppliers, especially the Crouch-Echlin people, also supply TD fixes.

Is it interesting that many software developers can supply TD solutions, yet I've been unable to locate anybody who has identified TD exactly, or who can rigourously illustrate it, or who can show a solution actually working ?:
   - How is software developed to fix a problem that is not accurately defined ?.
   - How is this software tested and approved, if the problem cannot be created/observed ?.
   - How can one be sure the "fix" works ?.
Magic ?. Brilliance ?. Snake-oil ?. Commentary - abundant; facts - scarce.

In our TD tests (as per the above examples), we did try some of these other "fixes". None worked.

If there is interest, I can prepare a "trial" download of the TD-fixer code. Let me know. However, without some code to identify if your PC has poor BIOS code, and some code to greatly increase the probability of TD, you may never observe the fix-code actually "working" !.

Michael Kennedy

[Top]
[ Home ] [ What's New ] [ Contact Us ] [ Referrals ] [ Feedback ] [ Products Summary ] [ DownLoads ] [ Orders ] [ Links ] [ Anti-Spyware ]