William John wrote:
> *** WHY *** would any outages occur? How can a simple date cause such
> problems? Can you (computer programmers) explain how the appearance that it
> is January 1, 1900 will do anything more than screw up billing cycles (for
> power companies, Social Security Administration and others)? Why should a
> bug like the 1900 vs. 2000 make much difference to power generation? (or
> computerized nuclear missiles and any other nightmare scenarios one can
> dream up)
Dates and times are used for more than just billing. They are used for all sorts of calculations, which I will exemplify below. Normally, time always goes into the future. When calculating how much time has passed, it always is a positive number. If the date goes backwards from 1999 to 1900, time periods suddenly go negative. If the program interprets negative numbers, it may calculate negative values instead of positive ones. If the program doesn't interpret negative numbers, then these numbers get interpreted as very large numbers because of the way data is stored. (The first bit can be used as a sign bit, showing a positive or negative. It also can be used as the top order binary digit, allowing larger positive numbers.) In either case, programs get unexpected values that are negative or very large. Such programs will then do unexpected things based on these numbers, or they very well may simply crash and/or hang the machine.
Some examples of date/time calculations:
Any machine (such as trains, planes, automobiles cruise controls) calculating how fast it is going (based on time calculations) suddenly gets a negative number and thinks it is going backwards and tries to accelerate to compensate. Or it gets a very large number and thinks it is going too fast and tries to decelerate.
Any machine (such as a printer, automobile, nuclear power plant) measuring time since its last maintenance suddenly gets a negative number and thinks it has a long time to go until maintenance is due and never stops for maintenance and so runs until it burns itself up. Or it gets a very large number and thinks its dangerously past maintenance and refuses to run at all until maintenance is performed.
Any machine (such as a medicinal IV drip) that meters out materials at a certain rate suddenly gets a negative number and thinks it is a long time until materials are due and so stops releasing materials. Or it gets a very large number and thinks it is way past due and so dumps out an extraordinarily high amount of materials to catch up.
Not only does billing get screwed up, but any machine trying to track speed, rates of delivery, time since maintenance, etc. can get screwed up.
Dates are also used to calculate the days of the week. Bank vaults may lock up on the wrong days. VCRs may record on the wrong days. Coffee makers may make coffee on the wrong days. Alarm systems, sprinkler systems, automated lighting schedules, power grid peak production schedules, automated trucking schedules, etc., may try to operate on the wrong days or not operate on the correct days.
Sometimes dates are important as well. Even though these may be "billing", consider if your credit card won't work because it expired in "1901". Consider materials or food being thrown out because it is past its expiration date of "1901". Consider your mechanic not performing proper maintenance on your car because his computer thinks it has a hundred years before your oil change is due. Consider all TV programming, automated factory schedules, banking transfers, trucking schedules, etc., all failing on computers and having to be done by hand by certain affected companies.
Sometimes the date calculations will just crash because of the bogus numbers. Imagine a cash register trying to print how many shopping days until christmas, trying to calculate 100 years of shopping days, overflowing the output field which is 3 digits long, and just crashing everytime it tries to print a receipt. Most programs don't expect simple date calculations to overflow into extremely large values, so they don't check for them. If they overflow, the program just crashes in many cases. Even if the dates aren't important for the operations, they still could prevent the machine from functioning due to field overflows.
These are just some ideas about what could go wrong. My predicition is that 99% of the errors will be fixed in time, but that the 1% left will wreak havoc. Imagine just one satellite failing, or one airport not being able to fly, or one major computer network being down, or one phone company going dead, or one state of the U.S. losing its power grid, or one stock exchange shutting down, or one brand of automobile to all go dead, or one brand of computer operating system to suddenly quit working, or one country mistakingly launching missiles. A small percentage of failure can cause widespread problems.
-- Harvey Newstrom <mailto:harv@gate.net> Author, Engineer, Entrepreneur, <http://www.gate.net/~harv> Consultant, Researcher, Scientist. <ldap//certserver.pgp.com>