Heard a rumor about a major utility in a developing country that is hopelessly behind in their y2k remediation, and is "planning" to turn the clock back to 1980 to buy additional time for making their y2k fixes. Is this really a viable strategy? If so, are their any particular risks? Especially for the embedded systems of their plant?

-- heidi dorfman (dorfmanki@home.com), April 25, 1999

Answers

I'm no pro here but, if I remember right, 1980 is not the right year to turn back to, and you can't turn a clock back in a chip. Sorry if I'm wrong , I'm sure some one will correct me if I am!!!!!!!!

-- SCOTTY (BLehman202@aol.com), April 25, 1999.

It could be a viable stopgap option in some circumstances.

One has to consider how calendar dates are used in the particular circumstances.

Because some computer code and business practices have incorporated knowledge about, and use of, calendar dates in an almost automatic, routine fashion over decades, it can be tricky (i.e., highly subject to oversight and error) to determine whether one has found all ways in which dates are used. (Basically, the whole Y2k problem has been caused by oversights in using calendar dates!) Thus, the safest way is to do a full Y2k remediation.

But suppose it is definitely known that (a) the "clock" really can be "turned back", (b) the only use of dates in a situation is the display or printing of current month and day, (c) the current year either is not displayed/printed or is readily and reliably ignored or masked-off, (d) year numbers are not used in any computory way such as sorting, (e) the time span of use will end before actual non-leap year 2100, and (f) day-of-week is not used in any way. Then it is viable to turn the clock from 1999 back to 1979, or next year from 2000 back to 1980, or by any other offset of a multiple of 4 years.

Risks? Overlooking an exception to one of the listed conditions.

If condition (f) does not hold (i.e., day-of-week is used), then turning the clock back 20 years won't work because the weekdays won't line up the same way with the days-of-month. For the combination of leap year and weekday to be the same, the offset has to be 28 years or a multiple of 28 years. So, 1999 -> 1971 and 2000 -> 1972.

-- No Spam Please (No_Spam_Please@anon_ymous.com), April 25, 1999.

heidi...You should know that two well-known people have advocated this trick in the past: One was Dan Quayle and the other was Bill Gates.

Dan didn't know any better. Bill knew better but didn't want to admit that his company may bring about the downfall of many companies. He decided it was more cost efficient to pay protection money to the mafia, pardon me, I mean the U.S. Congress. He (and others) will get legislated liability protection for an event that has yet to occur...if y2k is supposed to be "no big deal," why does he need liability protection?

-- PNG (png@gol.com), April 25, 1999.

Bill Gates did not pay "protection money" to the US Congress. Until Senator "bought and paid for" Arlan Spector came after Microsoft, neither Gates nor Microsoft donated to political campaigns at all. He, and his company, are under attack specifically BECAUSE he DID NOT pay "protection money".

Show your sources. To whom did either Gates or Microsoft give campaign contributions? Answer: none.

That is why they are after him! Duh!

-- Scott (duhelmet@aol.com), April 25, 1999.

Turning the clock back would only work in those cases where there are no program/data dependencies on past files/records with dates.

Microsucks would be a probably unintended beneficiary of the "Y2K non-liability" legislation. The thrust of this legislation, I gather, is to protect the banking, securities, utilities, other lareg corporations, AND government agencies from suits for damages, due to management's incompetence.

Actually, Microsoft and other software companies don't really need the legislation, as the "shrinkwrap contract" accompanying software says essentially that the software is sold "as is", is not guaranteed to work, and that the software vendor shall be held harmless for any damages, monetary or otherwise, when (not if) the software trashes your data.

-- vbProg (vbProg@MicrosoftAndIntelSuck.com), April 27, 1999.