You may not have known that the Y2K computer correction wasn’t really over on January 1^st. Companies still had the leap day of February 29^th as a concern for possible computer problems, and here’s why.

As everyone knows, the calendar isn’t perfect, and the reason is that there aren’t exactly 365 days in a year. And further, it isn’t exactly 365 and ¼ days either. If it were, adding a leap day every four years would work perfectly but … it’s more than 365.25. So to get the calendar eventually right, we need to skip the leap day every 100 years on years that are evenly divided by 100. But … and you guessed it … that still isn’t accurate enough because the calendar would be OVER-corrected if that was done absolutely every 100 years, so the plan is to skip not having it on years divisible by 400.

As a result, the years 1900, 2100, 2200 and 2300, even though they’re divisible by four, are not leap years because they’re divisible by 100. But since 2000 is divisible by 400, it is a leap year.

The temptation when writing code back in the 60’s 70’s and 80’s would be to just divide the year by four (actually for the math majors out there - take the modulus using 4 and test the remainder) because it would take care of all dates through 2099. I saw (and wrote – myself ) plenty of that kind of code. But, of course, it would have been no good if you were doing calculations on days in the past or future. For instance, on a 30-year house payment or a 100-year property lease, calculating the wrong number of days may throw the payment off by maybe the price of a cup of cappuccino.

So, when we spent the $100 billion the last couple of years for Y2K, we all did the right thing - right? We simply made it accurate from now on. So instead of calculating for a modulo 4, we also did 100 and 400.

And you’d thought you’d heard the last of this in January! u