|
|
 |
 |
 |
 |
   |
HOW DID WE GET INTO THIS MESS, ANYWAY?Think of a date--say, Feb. 10, 1998. In the U.S., no one would object if you wrote that date as 2/10/98. People would know what you meant. So there were no worries in the 1970s and '80s when programmers wrote software that represented years with only the last two digits rather than all four--''85'' rather than ''1985.'' Programmers thought they were clever since they were conserving memory, which was expensive back then. Despite falling memory prices, the practice continued into the 1990s--out of habit and inertia. Unfortunately, these programs interpret the year 2000 as 1900, which has the same last two digits. So any program with a date--billing, payroll, inventory, bank accounts--could crash or give misleading answers on Jan. 1, 2000, or before, since software that does scheduling or planning often uses dates a year or more in the future. For example, if a program figures the age of a person by subtracting the date of birth from the current year, then starting in 2000 it will look as if everyone less than 100 years old will have a negative age. Some other daunting errors: a missing paycheck, a scrambled bank statement, the shutdown of a factory, or a power plant's inability to deliver electricity. Or the software can simply freeze up. ''We feel you'll be a lot luckier if the system stops functioning,'' says Larry Olson, chief information officer for the state of Pennsylvania. ''It might be two months before you realize you're getting bad information.'' The Year 2000 bug also shows up in microprocessors built into machinery, from automated assembly lines to cellular telephones. ''Our biggest concern is that we miss an integrated circuit buried down inside somewhere that would have a cascade effect,'' says Bruce Colgate, process control manager at Phillips Petroleum Co. This is one bug whose effects may only be known when it bites.
|
Updated Feb. 19, 1998 by bwwebmaster
Copyright 1998, by The McGraw-Hill Companies Inc. All rights reserved.
Terms of Use