I just had a thought(don't laugh, it happens). When embedded chips with internal clocks were programmed, were they programmed for a straight 365 day calender, or were leap years inserted?

Since the internal clocks sometimes don't have any external function, it is basically used as a reference for that chip, so is this a possibility or not?

If so, they could fail days early.

Any tech types with answers?

-- CygnusXI (cygnus@black-hole.com), December 22, 1999

Answers

Unfortunately there are more answers to that question than there are different types of chips and systems. Consider these things:

Many controller/processor chips simply don't care about dates at all. Some only utilize elapsed time - that is, the number of time units that occur between two events. Many have no concept of a 'calendar'.

A single generic controller/processor chip may be used in thousands of different applications, many of which are not concerned with dates. Think of a generic controller/processor chip as essentially a huge box of unassembled Lego blocks. The individual blocks themselves do not care about stability. It's only when you build a structure with these blocks (i.e. writing the software that runs on the controllers) that stability becomes an issue.

Frequently, the programs written for such controllers are physically stored in chips seperate from the controller (called ROMs, PROMs, EPROMs, NVRAMs, etc.) that don't lose their memory when power is turned off. When a program is stored this way, we say it is 'burned into' ROM - that means it is not easily changable. (ROMs can only be programmed once and must be replaced when a chnage needs to be made, EPROMs can be erased with UV light and reprogrammed, etc. etc) Depending upon where that system is located, the task may be minor or it may be next to impossible.

The key point here is that for a large majority of programmable controllers, there is not a single 'program' that was written for the processor, but thousands of different programs written by thousands of different programmers for thousands of different applications.

Each individual programmer may have handled dates slightly differently.

In many cases, dates are simply not part of the application, but in some, they are. A controller can easily be Y2K-compliant when looked at in isolation but the application software (or firmware, microcode, driver or whatever you choose to call it) may not be. That's why knowing whether the controller itself is "Y2K-compliant" doesn't provide you with much information. You have to go deeper and ask whether the specific software that is running on a specific instance of a processor is date-sensitive and if so, whether it is Y2K compliant. Finally, even if it is determine to be 'non-compliant' you must go deeper and ask "What is the mode of the failure?" - in some cases it is insignificant, in others it is not. It's just about impossible to generalize here.

Systems today tend to built in layers - each layer hides the complexity of itself from the layers above and below it - or at least it should. Most often it is not the chips themselves that are date sensitive but rather the application software that is layered on top of such chips. Checking all programs on all chips everywhere might be, in the mathematical sense, a finite task, but one that could not be accomplished in our lifetimes. Some 'fix on failure' was inevitable.

-- Arnie Rimmer (Arnie_Rimmer@usa.net), December 22, 1999.

italics off!

-- Arnie Rimmer (Arnie_Rimmer@usa.net), December 22, 1999.

One of the points mentioned regarding embeddeds is that they ARE programmed for leap years, and the testing was done in 1900's but not in 2000. The chip locks up its inputs and outputs for some number of machine cycles, while it computes the time, and does this every so many cycles. Dunno the numbers, sorry, and don't have the thread.

Turns out that because the year 2000 is a leap year even tho its a thousand, it takes an extra couple processor cycles to compute the date, and that creates an error possibility. That timing window unlocks while the date/time is still being calced, and the chip can output a garbage date as a consequence.

This is all from [poor] memory.

-- bw (home@puget.sound), December 22, 1999.

That should be "even tho it's divisible by 400", I think.

-- bw (home@puget.sound), December 22, 1999.