Most material I've seen recently (including chapter 11 of Ed's book) suggests that for the most part, embedded chip problems will surface at midnight of December 31, 1999. My question is this. Since embedded microprocessors are manufactured in various locations (from Malasia to California to Massachusetts to England), is the time zone (and date) of the geographic area where they were built used to establish the Y2K rollover date for the chip? If the rollover dates are a function of where the chips were built (and firmware programmed), then failures, malfunctions or anomalous behavior of the devices may not occur at midnight in the time zone where the device is currently in service. This means that chip problems can potentially occur up to +/-24 hours from midnight, December 31, 1999. In addition, the quartz clocks in these devices do not keep perfect time. This will also serve to spread out the distribution of date-related failures of embedded systems over a larger period of time than just an hour or two on either side of midnight. My guess is that significant problems with embedded sysytems will have a Gaussian distribution in any given time zone with the peak number of malfunctions occuring around midnight. Any comments?

-- Brian E. Smith (besmith@mail.arc.nasa.gov), August 10, 1998

Answers

I've recently wondered the same thing. Seems logical to assume that you're on the money here, Brian.

-- Nabi Davidson (nabi7@yahoo.com), August 10, 1998.

One well-written paper I saw by an engineer suggested that it's not just a +/-24 hour window. While chips that, in their actual use (application), keep track of the date are at substantial risk of 1/1/2000 problems, the ones that measure elapsed-time are a different story.

From what I *read* (I don't even play an engineer on TV), the elapsed-time chips are generally built using generic chips that actually DO track the actual date. It is just that the actual date feature is not being used. The elapsed-time feature, though, *internally* uses the date and is subject to "roll-over" problems (1/1/2000).

What is different about elapsed-time chips is that the internal date is set to an unknown (essentially random) date. While the chip will fail some-day, it has no reliable relation to the actual date of 1/1/2000. Since the date on an "elapsed-time" chip is not used externally, there was no reason to accurately set the date/time.

-- Anonymous (Anonymous@anonymous.com), August 11, 1998.

It all depends.

If the embedded system needs to know the date, it may be Y2K-buggy and normally that's 1/1/2000 unless it does date look-ahead. This is a matter of how the embedded system was programmed and is not determined by the particular chip or board used in the embedded system

The other case is where there is an UNUSED realtime clock within the hardware, and that clock is mis-designed at the silicon level so it will cause mischief when it reaches 2000 even though the designer of the embedded system isn't looking at the date at all. Note: this describes a small minority of embedded systems. Most realtime clocks will not cause a Y2K problem merely by existing. However, for the minority:

(a) the realtime clock is battery-backed and was set at the factory. In this case the trouble will strike when it reaches 2000 in the factory timezone (plus or minus timekeeping inaccuracy). That'll be +/- 24 hours of 1/1/2000 in almost all cases.

(b) the realtime clock isn't battery-backed and resets to some arbitrary date every time the power goes off. In this case there will be a problem only if the device is powered continuously for many years, and the bug may manifest at any time after 2000.

(c) the realtime clock is battery-backed but is not set at the factory. In this case loss of power won't reset the count, and a Y2K failure will occur at a future date N years after the device was assembled. (N is often 20).

(a) is the worrysome case. (b) and (c) will probably get diagnosed as hardware failures and fixed by replacement of the unit; since there's no sudden glut of synchronised failures there won't be any problem above that which would have been caused by failure for any other non-clock-related reason.

-- Nigel Arnot (nra@maxwell.ph.kcl.ac.uk), August 11, 1998.

Nigel,

<< (a) the realtime clock is battery-backed and was set at the factory. In this case the trouble will strike when it reaches 2000 in the factory timezone (plus or minus timekeeping inaccuracy). That'll be +/- 24 hours of 1/1/2000 in almost all cases. >>

Only if the clock uses actual dates where years are represented as two digits. If the clock/firmware combination is tracking time a different way weeks since some arbitrary date set by the manufacturer, for example) you will hit a rollover problem when the register counting the units passed rolls over. If weeks is the increment you are back to your problem approx. 20 years after the device goes into service (actually, the 1025th week, which is 19 years and not quite 9 full months).

-- Paul Neuhardt (neuhardt@ultranet.com), August 11, 1998.

Paul,

Sorry to be pedantic, but if it's not related to a two-digit year representation it's not a Y2K bug, it's some other sort of epoch bug. I'm quite aware of these but I didn't think they were relevant to the question.

-- Nigel Arnot (nra@maxwell.ph.kcl.ac.uk), August 12, 1998.

Nigel,

Basically I agree with you. However, there are two reasons I bring this type of problem up.

1) It is a rollover problem, and Y2K is simply a specific type of rollover problem.

2) There has been a lot of discussion here about other rollover problems no related to Y2K per se. The GPS rollover in September of 1999 and automobile engine control systems, for instance.

However, your point is well taken. The circumstances I described are not rollovers that occur because of the mishandling of two digit years and as such are not "Y2K" problems even though they are very similar in both cause and effect.

-- Paul Neuhardt (neuhardt@ultranet.com), August 12, 1998.