(This column was first published in the February 28, 2000 Buffalo News.)
We seem to have made it through Y2K without too much difficulty, although I understand that there were some problems with our military satellites. But it will be interesting to see if February 29th creates an additional glitch.
What would be the problem? The problem is that this year 2000 is a leap year. Everybody knows that, you might respond, since every year divisible by four is a leap year and 2000 is certainly divisible by four.
Consider a little astronomy and arithmetic. It turns out that our year, the time it takes for the earth to make a single revolution around the sun, is very close to 365.2422 days. If we simply make every fourth year a leap year, we have 365.25 day years, not far off and that .0078 day difference is only about 11 minutes and 14 seconds. (You can easily check that by multiplying .0078 day x 24 hours/day x 60 minutes/hour.) However that small annual accumulation of .0078 day will lead to a full day in about 128 years. (Calculating that is still easier. Enter .0078 in your calculator and press the 1/x key, immediately converting days/year to years/day.)
To further correct for this, our current Gregorian calendar makes two adjustments: (1) even though they are clearly divisible by four, years divisible by 100 are not leap years, (2) except for those divisible by 400 which are leap years.
Thus 1900 was not a leap year, but this year we have the most unusual case of all -- 2000 is divisible by 400 so it is a leap year. This remarkable situation will not occur again until the year 2400.
Now we can return to our inquiry: What is the problem? The problem is that this is another of those cases where a little knowledge is a dangerous thing. Some programmers, I understand, applied the 100-year exception but not the 400-year further exception. Any computer so programmed will make tomorrow March 1 instead of February 29. Now that isn't nearly as serious a problem as the year 2000 turning out to be 1900, but it certainly will mess things up if and when it occurs. Notice, however, that this is a case where even less knowledge turns out to work better. If a programmer only knew the "divisible by four" rule, his or her programming would be okay -- until the year 2100, that is. (In that year, as things stand, our ancestors are going to have a Y2.1K problem anyway.)
It turns out that even our Gregorian calendar accumulates errors over time. Its corrections make the year 365.2425 days long, still in error by a seemingly insignificant .0003 days or about 26 seconds. But since the Gregorian calendar was first introduced in 1582, that has already amounted to an error of over three hours. By the time our offspring reach Y5K another adjustment will need to be made. (Clearly these are not problems for us to worry about.)
That is the bad news. I temper it with some good news for a few of you parents. If you know of anyone whose child was born on November 30, 1999, please pass along this information.
Those children will have a special ability to tell their age in years, months and days simply by referring to the calendar. For example, today's date in abbreviated form is 02/28/00 and those November 30 babies will be exactly 2 months and 28 days old.
Now suppose one of those youngsters gets married on March 15, 2023. In abbreviated form, that will be 03/15/23 and the young man or woman would be 23 years, 3 months and 15 days old.
Note that anyone born within a short time of November 30, 1999 would need only to add or subtract the difference in order to apply this unusual rule. (For example, a friend's twins were born on January 5, 2000. The twins can use the rule by reducing the number of months by one and the number of days by five.)
Lucky them.-- Gerry Rising