29th February, 2000

Er ... Dave ... There is a 29th of February in the year 2000 ...

This fact follows from the leap year rule for the Gregorian Calendar: In the Gregorian Calendar (for years from 1 A.D. onward) and in the Common Era Calendar (for all years, positive and negative) a year is a leap year if it is divisible by 4, except if it is divisible by 100, except if it is divisible by 400. Or in other words: All years divisible by 4 are leap years except for years divisible by 100 but not by 400. Or again: If a year is divisible by 400 then it's a leap year, otherwise if it's divisible by 100 then it's not a leap year, otherwise if it's divisible by 4 then it's a leap year, otherwise it's not.

On the CALNDR-L mailing list Ken Pizzini recently remarked:

"The concern is that a program might roll over straight from 2000-02-28 to 2000-03-01. This might be because the programmer knew/remembered only the first two of the three parts of the leap year rules, or it might be because they forgot that the "natural form" of the year in their system is not (400 year-) aligned with those of our calendar. An example of the latter would be a C program which forgot to take into account the 1900 year offset of the tm_year member of struct tm.

"Many programs will get this right; a not insubstantial number of them for the wrong reason (i.e., they only know about the 4-year rule). But because it _can_ be done wrong, one needs to check to see if it _has_ been done wrong in one's systems."

As Ken points out, 2000-01-01 is not the only date in the year 2000 that we need to be concerned about — another dangerous day is 2000-02-29. It may be assumed that a lot of software which is now relied upon for critical tasks was written by programmers who were not aware (and maybe even still don't know) that the year 2000 is a leap year. They thought: "Years divisible by 4 are leap years, except if divisible by 100, so 2000 is not a leap year — better check for this." They were unaware of the "except if divisible by 400" part of the leap year rule.

So there will be some programs that assume that the day which follows 2000-02-28 will be 2000-03-01, and when this does not happen these programs may malfunction, with unpredictable consequences.

Such consequences could be very expensive, as in the case of the aluminium smelter in New Zealand which automatically shut down on 1996-12-31 because the programmer who wrote the software controlling the factory had not taken into account the fact that 1996 had 366 days, not the usual 365. On 1996-12-31 the software was confronted with "Day 366", which it assumed was impossible. "Something is wrong," it said, "very wrong." So it shut the plant down, including the furnaces. The molten metal solidified and the damage ran into millions of dollars. (More on this at Year 2000 Incidents.)

Date Validation — Is this a Leap Year?
C/C++ Programming	Home Page