Buggin Out Over Leap Year Another Computer Bug Looms Around Corner

John Koskinen, chairman of the President's Council on Year 2000 Conversion, has released a warning over possible computer problems with the upcoming leap year on Feb. 29. (Joe Marquette/AP Photo) By Erica D. Rowell

N E W Y O R K, Feb. 24  Not quite two months ago, the year 1999 rolled smoothly into 2000, with the smallest of whimpers from potential Y2K bugs rather than the media-hyped big bang.

But now another red-letter date looms around the corner, posing a possible bump in this new millennial leap year. Will electronic calendars recognize February 29th? Or will they incorrectly jump from February 28th to March 1st?

The potential problem is substantial enough for Y2K guru John Koskinen, chairman of the Presidents Council on Year 2000 Conversion, to schedule a press conference today to discuss the February 29 leap-year rollover period and the challenges it poses to information systems. These challenges, which do not pose as great a problem as the Y2K issues did, are more likely to manifest themselves in software applications rather than hardware, says Council spokesman Jack Gribben.

We dont have a sense that the leap year is going to cause significant problems, said Gribben. Its a little bit different from Y2K. Its more of a result from error in programming. Counting the Days As most people know  especially those born on February 29th  this year is a leap year. But the year 2000 presents a special programming anamoly.

Heres why: Instituted by Pope Gregory XIII in the late 1500s, the Gregorian calendar, the standard keeper of time for much of the world, normally consists of 365 days. This number is an estimation of the so-called sidereal year, which is the actual length of time required for the Earth to revolve once around the sun; a sidereal year consists of 365.2563612 mean solar days.

Every four years, an extra day is added to the Gregorian calendar to eliminate the difference between the true number and the estimation; however, even with this adjustment, a small difference remains. So there is an added stipulation to the leap year rule: a year that is evenly divisible by 100 is a leap year, but only if it is also evenly divisible by 400. So 1700, 1800, 1900 and 2100 are not leap years; 1600 and 2000 are. A programmer, then, must remember that the year 2000 qualifies as leap year, even though it also meets the divisible by 100 rule. In case some programs were written without regard to this, the Council plans to monitor the financial sector, insurance sector and other areas where dates are part of billing or record keeping, which could be vulnerable to such coding errors.

Bug or Bugaboo? Based on how incredibly over-hyped the Y2K bug was, the only people who need to worry about Feb. 29 are the computer consultants who were counting on another fat paycheck, says Jeff Stonier, senior programmer at Radio Computing Services, a software company based in White Plains, N.Y., that specializes in software designed for the radio industry. Stonier calls Feb. 29th a non-issue even on software that was built in complete ignorance of the leap year exceptions. If you were unaware of such a thing of a leap year exception, if you didnt do anything special, your program will work, because it is a leap year, Stonier says. In other words, those programmers who were unaware of the exception rule to years evenly divisible by 100 would at least have known that 2000 was a leap year, and the program would work just fine. In this instance, any leap-year-related problem wouldnt actually crop up for 100 years until 2100  when it would certainly become a non-issue.

Hard to Crack the Code For those programmers that took the trouble to code the leap year exception, they would have to be pretty thick to code correctly for 2100 but not for 2000, Stonier says. Senior software engineer Mark Roman tends to agree: Software that screws up on leap years is inordinately sloppy. There is a UNIX calendar program that incorporates all the rules for leap years, adds Roman, who works for net.Genesis, an Internet start-up in Cambridge, Mass. While neither Stonier nor Roman denied outright the possibility of leap-year-related bugs, both agree the outcome of such problems would have minimal impact. And even Gribben admits that there is a good chance that many of the problems that might have appeared with the leap-year exception were probably addressed during Y2K preparation.

Still, the presidents Y2K council will organize the same structure of monitoring and support for federal and state organizations as it did when the world ushered in the new millennium.

Future Bugs And the possibility remains of future calendar hazards. There will always be date bugs to write about, says Stonier. There are a hundred different dates on which some piece of software or other will fail. Romans favorite is the Y2.036 bug. A lot of computer systems and application software reckon dates as the number of seconds since midnight on Jan. 1, 1900 (the epoch.) The count is stored in a data type that is an integer with 32 bits, so eventually it will reach a finite number that will cause the count to wrap around to zero again.

The number is 4,294,967,295. If you divide all of the number of seconds in a year into that number you run out of room somewhere in the morning of 5 February 2036, says Roman. Mark the date.

http://www.abcnews.go.com/sections/tech/DailyNews/leapyear000224.html

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