Companies and government agencies are taking some modest precautions to keep an eye out for leap year date glitches that may have been missed in year 2000 testing.
But the biggest problem may be getting workers to be on the lookout for errors, especially after the relatively problem-free year 2000 rollover.
"It's been a little bit of a struggle to get people to take it seriously because we were so very successful with the millennium," said Mickey Galatola, the Y2k manager at PECO Energy in Philadelphia. "But one thing that's different is that this is a workday. I keep emphasising that I don't want anybody to show up and not be able to geton their system. That's why it's so critical, so people are taking it seriously."
PECO's information technology managers will meet at 8:15 on the mornings of February 29 and March 1 to review overnight test results. If anything has gone wrong, senior managers will be notified, said Galatola.
The fact that this is a leap year may not have been obvious to programmers.
Years divisible by 100 are normal years, and if programmers used that rule, they treated the year 2000 as a normal year. But the year 2000 is a leap year because it is divisible by 400. If programmers weren't aware of that, it may be understandable: The last time that happened was in 1600.
The relatively problem-free Y2k transition has led John Koskinen, who headed the White House's year 2000 effort, to be confident that the leap year won't cause many glitches. "It's unlikely that systems are going to collapse; it's unlikely that we're going to have major issues at all," he said.
The White House plans to revive its year 2000 operations centre to watch for problems next week, but not to the same extent that it tracked the year 2000 problem.
John Burns, vice president of projects at Canadian Imperial Bank of Commerce in Toronto, said he found two kinds of leap year problems. Some software didn't recognise February 29 as a valid date. Other programs, such as those calculating interest on loans, didn't account for the extra day.
The bank won't have IT staff pulling all-nighters February 28, Burns said, mainly because its year 2000 rollover went so well that it doesn't anticipate problems. "We will have key technical people on call but won't man any command centres," he said.
Kathy Donovan, an application technology manager for the state of Delaware, said that if problems do occur, they will be easy to recognise and fix. Unlike the year 2000 problem, the leap year date glitches aren't likely to be buried in code. "The risk is pretty small, but there is always the potential," she said.
At Agricredit Acceptance LLC, leap year work was done at the same time as year 2000 remediation, said Bruce Cheek, IT manager at the financing company in Des Moines, Iowa.
Except for one input screen in a credit application, all Agricredit's software withstood the February 29 challenge during testing, Cheek said.