Usually when I bring this up when the discussion turns to the Y2K crises (old war stories in the IT section), most people look at me like I just grew another head. But it is still interesting its own right: the Centennial Leap Year problem.

Allow me to explain: The Earth's orbital period around the Sun - the tropical year - is approximately 365 1/4 days (365 days, 6 hours). Because of the extra 6 hours, the Gregorian calendar which most of the world now uses adds an extra day to the end of February every year which is evenly divisible by four – the leap year. However, in reality the Earth's tropical year is not precisely 365 days 6 hours, but closer to 365 days 5 hours 49 minutes. This 11 minutes discrepancy adds up over the years; over the course of a century the Sun and the calendar are out of line by a little more than 18 hours (3/4 of a day).

To correct this discrepancy, it was decided by the Catholic church during the papacy of Pope Gregory XIII in 1582 that every year that is exactly divisible by four is a leap year, except for years that are exactly divisible by 100; the centurial years that are exactly divisible by 400 are still leap years. For example, the years 1800, 1900, and 2100 are not leap years; the year 2000 is a leap year.

So much for background. The point is, it was only a historical accident that the computer technicians didn't have to deal with a problem that would have been at least as vexing as the Y2K problem. If technology had progressed a little more quickly over the ages than it did, civilization would have had to deal not only with the "Y1.9K" problem, but also with the Leap-Year-That-Wasn't problem.

Every program I've ever seen (or at least the ones that were competently written) that had to deal with dates took leap years into consideration by dividing the year by four and if the remainder was zero invoked a subroutine to add the leap day. Fine – until we get to a century year where that subroutine would throw meticulous calculations out of whack.

But fortunately for our generation, the century year 2000 was evenly divisible by 400, therefore a leap year, and therefore we didn't have to deal with yet another troublesome problem. Ninety years from now our decedents will be fretting about this "Y2.1K" problem, but by then it is very likely that everyone who is now reading this post (or at least everyone over the age of 10) will have been safely planted. If the scholars of 1582 had bothered about these IT matters, one wonders how the Gregorian calendar might have been adjusted.

The 400 year rule is probably not known generally, but I would think it is pretty common knowledge among programmers. Wouldn't this rule have been built-in to most systems that need to generate date information?

Computer programmers come in varying levels of skill and meticulousness. In the beginning, the two-digit year field might have been justified because of the relative expense of computer memory. However, by the 1990's the cost of memory became economical enough to invalidate the logic of trimming the years from four digits to two.

Outsiders may not think so, but I assure you the "That's-Not-The-Way-We-Do-Thin­gs-Dear" mentality permeates the Information Technology field as much as any other you may name. Some of the more hind-bound programming managers insisted that year date fields be defined as two digits because that was the way they were taught to do it and, by God, that will be the way it will be. Also, the "I'd-Rather-Have-It-Thursday-T­han-Right" attitude by customers and managers encouraged corner-cutting by programmers. I had to modify some programs that didn't acknowledge the existence of leap years; obviously the programs were not fully tested before being put into production.

Software programs were written with the Y2K date flaw in them long after the Y2K concern became generally acknowledged. If some programs couldn't accommodate four-digit years and even allow for leap years, I have little confidence that they would readily understand the concept of non-leap year century years.