Bill - You are right about the date being used in timestamping and report generation, but that does not imply that the full date would be used in the rate change calculations. In fact, it would be more work and more CPU cycles to use the full date and it gains you nothing. (unless your sample period is very long)... you can still reference the full date in a report.
Other than the most sophisticated embedded systems (i.e. very few) qould you have the accuracy necessary to *never* need to reset the clock to the actual time. The time drift would mean that you would have to readjust the clock periodically... therefore you need some sort of interface to do that. ... heart machines, vavle controls, embedded relays have no such interface for setting the date.
I am not saying that there will be no Y2K failires at all, but they will be related to date comparisons in report generating *not* in embedded systems.
The Y2K bug that some of our products have had is this: the user is unable to set the date 2/29/2000 because the firmware does not think it is a leap year. (years divisable by 100 are not leap years unless divisable by 400). Why the programmers even *bothered* to test for divisable by 100 is beyond me. If they had just left it as div by 4 they would have been fine until 2100 when the equipment was rusted and in a junk yard. But the real point is WHO CARES THAT YOU CANT SET THE DATE 2/29/2000 .... but never-the-less we had to fix the equipment to be able to claim Y2K compliance.
Here is my view of the Y2K phenomenon ... beginning about 5 years ago when this topic started to get more attention companies were asked are they Y2K compliant ... as they began to investigate they found issues, mosyly of the benign nature that I illustrated. Although since the systems are complex, they were advised by the gaggle of lawyers to say they were not fully compliant and they were working to become compliant. That would allow them to 1) sell upgrades, 2) avoid lawsuits for lying. The next thing that happened were the entrepreneurs that saw the opportunity to make bundles of money "evaluating" peoples systems for the Y2K bug. This led to whole industries to support the evaluating and fixing of the bugs. Our company has spend millions on "eradicating the Y2K bug".
So, much of the Y2K story has been vastly overblown, especially in the embedded systems. Older business apps will experience problems but they will unlikely be noticible for very long.
Of course, ATMs will fail, Power will go out, computers will crash, etc but it wont be any different from any other day, except that this time it will be blamed on the "Y2K bug".
Looking to incite more insight into this ... :-)
Cruiser |
