Leap year problem revives some Y2k-like worries

By Patrick Thibodeau, Kim Nash and Kathleen Melymuka 02/24/2000 As a result of a rare exception in the rules used to calculate a leap year, it's possible that computer systems may not recognize the year 2000 as a leap year and run into problems next week.

Big problems aren't expected. For the most part, checking for the leap year was part of the year 2000 effort, said information system managers at private companies and government agencies.

Despite that, some companies are taking modest precautions.

"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, Y2k manager at PECO Energy Co. in Philadelphia. "But one thing that's different is that this is a workday. I keep emphasizing that I don't want anybody showing up and not being able to get on their system. That's why it's so critical, so people are taking it seriously."

PECO information system managers will meet at 8:15 a.m. on the mornings of Feb. 29 and March 1 to review overnight test results. If anything has gone wrong, senior managers and directors 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 to identify leap years, then their systems will treat the year 2000 a normal year. But the year 2000 is a leap year because it is divisible by 400  a rule that supercedes the previous rule (see chart).

Programmers may not have been aware of the rule conflict, however. The last time that happened was in 1600.

Despite that, John Koskinen, who headed the year 2000 effort for the White House, isn't expecting many glitches.

"It's unlikely that systems are going to collapse; it's unlikely that were going to have major issues at all," said Koskinen.

The White House plans to revive its year 2000 operations center to watch for problems next week, but not to the same extent that they 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 recognize Feb. 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 Feb. 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 centers," he said.

Kathy Donovan, an application technology manager for the state of Delaware, said that if problems do occur they will be very easy to recognize and fix. Unlike 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 of Agricredit's software withstood the Feb. 29 challenge during testing, Cheek said. The company fixed the errant screen - part of a four-year-old homegrown program - months ago.

"This is not huge. We said, 'Let's not have people sitting in here overnight' " on Feb. 28, Cheek said.

http://www.computerworld.com/home/print.nsf/all/000224EF5E

-- Martin Thompson (mthom1927@aol.com), February 27, 2000