Now for the other Y2K problem: It's a leap year
March 5, 1999
by Mitch Betts and Tom Hoffman
(IDG) -- Starting this time next year you'll find out whether your computer systems can handle the other year 2000 problem.
Next year is a leap year, a calendar phenomenon that historically has driven computer systems nuts if they fail to account for the extra day, Feb. 29. The last leap year, 1996, saw numerous snafus, including a New Zealand aluminum smelter that literally had a meltdown when the computers shut off; they weren't programmed to handle a 366th day.
Computer glitches crop up every leap year -- even though the problem is well-known -- because date arithmetic errors are repeated in new programs, said computer scientist Peter G. Neumann, author of Computer Related Risks.
The culprits are sloppy programming and short-sightedness, he said. "The same damn things keep happening over and over and over again, because people don't learn from history."
Especially worrisome is that, in a Computerworld survey of 105 information technology managers, 17% didn't know 2000 is a leap year. "2000 is gonna be a stinker because there are a lot of people that don't understand whether it's a leap year or not," Neumann said.
The confusion arises because the rules for determining leap years are more complicated than the "every four years" rule taught in grade school. There are two other factors: Years divisible by 100 aren't leap years, except that years divisible by 400 are. So 1900 wasn't a leap year, 2000 will be and 2100 won't be.
The survey found that many large U.S. corporations appear to be addressing the leap year issue at the same time they fix the "00" year rollover problem. Seven in 10 respondents said they expect to have their systems ready for the leap year by June, and the rest expect to finish by year's end.
Many IT executives said they would be surprised if other companies haven't factored the leap year into their year 2000 planning. "It would be silly for companies to miss this. [Leap year] has been talked about for so long it shouldn't be a problem," said Michael Radcliff, vice president of information systems at Owens Corning, a Toledo, Ohio-based building materials supplier.
But history isn't on the optimists' side. Virtually every leap year in the computer age has had glitches, including the following episodes in 1996:
In fact, 7% of the IT managers surveyed by Computerworld said their company had experienced leap-year systems problems. And 22% of the respondents said they are concerned about the leap-year compliance of their trading partners' systems next year.
"The sophisticated [organizations] know it's a leap year," said Capers Jones, chief scientist at Artemis Management Systems Inc. in Burlington, Mass. But for those that haven't factored it in, Jones estimated that 10% to 12% of the applications that handle the century change "will miss the leap year part of it."
Companies looking solely for "00" date rollover problems will miss leap year and daylight-saving time problems, Neumann said, because they show up in different parts of the code.
Vigilance is the key. MBIA Inc., an Armonk, N.Y.-based insurer of government bonds, already has identified a third-party portfolio management application that hadn't included the extra day in its original year 2000 remediation.
MBIA contacted the vendor and discovered that a leap-year patch was in the works. "But it proves that there's never complete assurance in third-party software. It behooves any organization to do a double-check," said Michele Lachiusa-Likens, a consultant working on the year 2000 project at MBIA. A software tool from Princeton Softech Inc. in Princeton, N.J., which "ages" a program to see if it works on particular days, found the problem.
Another daunting Y2K task: Educating America's masses
RELATED IDG.net STORIES:
Blame it on Pope Gregory
|Back to the top||
© 2001 Cable News Network. All Rights Reserved.|
Terms under which this service is provided to you.
Read our privacy guidelines.