I realize that many who follow this forum are not computer programmers and may not be aware that there are actually two separate computer problems. The first and most commonly known problem is of course the use of two digit years with an assumed century of '19'. This leads to all kinds of problems when then century should be '20' and is the problem almost exclusively talked about. A second problem has arisen on year 2000 rollover which is much harder to explain and has been christened "Time Dilation" (TD) by codeheads. TD is a random acceleration (usually) as seen in the BIOS (Basic Input Output System) and read by any application program that just happens to be running. The application program can be absolutely one hundred percent Y2K compliant and be brought down or corrupted by this problem. Unless you understand assembler language, the exact explanation would be pretty meaningless. The summary explanation might go like this. On century rollover (19 to 20), the BIOS as programmed in probably 50%(could be more) of all PC's (and some programmable logic controllers ala "embedded systems") will intermittently and erroneously increase the system date available to other programs in the computer. A real life test showed one computer aging 3 months in one week of continuous operation. A few systems might actually regress if enough random cummulative error is more negative than positive (not confirmed yet). TD has gotten zero press and most Y2K aware people are surprised when I tell them.

This is an ominous turn of events because many organizations aren't even aware of the problem. It increases the vulnerablity of networked systems (especially distributed processing). I don't know yet if this error has been found in workstations but its almost certain to be in some servers. It also suggests that just getting past 1/1/2000 to 1/2/2000 is NOT good enough. Wanna have fun? Call up the Y2K coordinator of your local utility and ask them about their progress on TD!!!!

Just decided to buy another gun (Ruger Mini-14) and more food (MRE's).

-- R. D..Herring (drherr@erols.com), September 19, 1998

Answers

Do you have a link to any info about this on the internet? I know about the rollover problem, but what you describe is something different. Please show us more.

-- Mike (gartner@execpc.com), September 20, 1998.

Mike

Go to the thread achives on this forum, then to the PC catagory, you will find a Time Dilation thread with more info.

-- Uncle Deedah (oncebitten@twiceshy.com), September 20, 1998.

I just read some of the stuff Mike Echlin has posted about TD. It looks like the problem may not exist in Pentium PCs, which is good for my company - we only have a couple of 486s still in service. Overall, however, this is more bad news. Thanks to R.D. for the original post.

-- Mike (gartner@execpc.com), September 20, 1998.

I've read about this problem somewhere else, but that article didn't seem to have any answer about what causes it, or if its possible to fix it. Anyone know?

-- Sheila (sross@bconnex.net), September 20, 1998.

This might help:

http://www.intranet.ca/~mike.echlin/bestif/index.htm

-- Mike (gartner@execpc.com), September 20, 1998.

My apologies to Crouch/Echlin for not giving them full credit for TD. I was unaware of its exact history. Mike's reference to the Echlin web site is a great resource and should be read by all. The curious thing is the reference to the loss of a com port during TD. The 244 msec theory sounds plausible for getting garbage from the RTC, but it doesn't explain the com port loss. It suggests either more than one mechanism is at work or a more complex singular reason.This strikes the fear button because it also affects known embedded systems. Lastly, they have confirmed TD in at least one Pentium class machine.

-- R. D..Herring (drherr@erols.com), September 20, 1998.

Maybe the reason this has not gotten much press is that there isn't much research there. A few tests run on a 286, 386, and 486 don't prove much.

-- Buddy Y. (buddy@bellatlantic.net), September 21, 1998.

Its a difficult test also, one that will interfere with other "work" going on the PC being tested, and one that requires a lot of time. Even if the single PC tested is "okay" (measured against what standard, if the TD effect is small ), then all the test means is that one PC running one Op system with one particular BIOS works. That leaves a lot left.

Also: consider my own problem: I've got a 486 running DOS 6.22 and Win 3.1 at home for games and homework and our checkbook program. If I test its process with a date advance, then my checks are written with the wrong date. If I "reset" the date to print checks, than I lose the time dilation evaluation.

Same thing (but more involved) would happen to others testing process control PC's.

What the heck!!! Time dilation will just speed that thing up anyway, won't it?

-- Robert A. Cook, P.E. (Kennesaw, GA) (cook.r@csaatl.com), September 21, 1998.

A somewhat related problem with PCs that has not gotten a lot of publicity has to do with their real-time clocks. In theory, as long as the BIOS correctly compensates for a non-Y2K compliant real-time clock, applications should not be affected. But, in practice, it turns out that there are some important applications that get their date data directly from the RTC. See the 9/5/1998 INFOWORLD ELECTRIC article "Users are dodging noncompliant real-time clocs" at http:// www.inforworld.com/cgi-bin/display/Story.pl?98095.ehrtc.htm

-- Joe (shar@pei.com), September 22, 1998.

Tried to follow the URL for Joe's RTC ref but it failed. The root .com is a Spanish web page. RTC's are usually simple counters. No date is stored per se. Instead, its the number of seconds from a given archive start date/time. Please re-post Url if its available. Thanks----

-- R. D..Herring (drherr@erols.com), September 22, 1998.

Sorry for that goof! This should work for you ... http://www.infoworld.com/cgi-bin/displayStory.pl?98095.ehrtc.htm

-- Joe (shar@pei.com), September 24, 1998.

Does Digital Equipment have any info about Crouch-Echlin (TD) online? If they do, I'd like to read it. With their resources, they ought to be able to get alot of research done in a hurry. Please post a link if you know of anything.

-- Mike (gartner@execpc.com), September 26, 1998.

This is just a comment, but I read (and I cant remember where) about a company that let their computers roll over to Jan 1,2000 and it worked o.k. But they left it run and checked it 38 days later. The date read January 38,2000. Is the same thing as the original post? And has anyone read the same thing? It shows that even if companies DO do roll-over testing and stop there -that that wont be enough !

-- madeline (runner@bcpl.net), September 26, 1998.

madeline:

I didn't see anything like that in the stuff I read about Crouch-Echlin (TD). I would be interested if you had anything more, especially a link to a Web page. That reminds me of the old joke: What time is it when the clock strikes thirteen? - Time to get a new clock.

-- Mike (gartner@execpc.com), September 26, 1998.