Even as the so-called year 2000 problem has many computer services executives fixated on Jan. 1, 2000, two other dates are competing for attention.
Sept. 9, 1999, and Feb. 29, 2000, each could be occasions for widespread system malfunctions and crashes because of quirks in certain types of computer codes.
Some banks have known about the threat posed by these dates for some time, but many others became aware only recently.
"The reason these problems seem like a new thing is because you have a lot more businesses beginning work on the year 2000 problem, and they're just learning about the other date-related problems," said Lou Marcoccio, research director at Stamford, Conn.-based Gartner Group.
Year 2000 projects require modifying computer codes to ensure systems do not mistake references to 2000 for 1900, which could cause inappropriate calculations and other havoc. Such errors could occur because old-style programs referred to years only by their last two digits.
The September date could be dangerous because many programmers used the numbers 9999 as a command to cease certain functions. Malfunctions could occur because these same digits would connote Sept. 9, 1999.
The February date is troublesome for an even stranger reason: Many programmers may have been unaware of its existence.
Since the last year of each of the last three centuries contained no Feb. 29, many programmers might have assumed that 2000, too, is not a leap year. But every fourth century, this rule does not hold. There will be a Feb. 29, 2000.
Though fixing the February and September problems is not difficult, finding them within programming code can be time-consuming.
The fact that other unexpected problems might arise as 2000 approaches means banks that have not started to address the issue should begin immediately, experts said.
