TD - (Time Dilation / Time/Date Jumps)
|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 -
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
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
- 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
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
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
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
- TD can be easily demonstrated (contrary to Intel's
- 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
- 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
- As the speeds of PCs increase, the probability of TD
- 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
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
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.....
|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
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
- 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" !.
[ Home ] [ What's New ] [ Contact Us ] [ Referrals ] [ Feedback ] [ Products Summary ] [ DownLoads ] [ Orders ] [ Links ] [ Anti-Spyware ]