The last *big* leap year bug i experienced was in 2000, because hardly anyone implements the full 4/100/400 leap year rule in their code. Modern libaries do (for the most part), but there's a lot of homebrew/DIY code from people who don't appreciate the subleties of date/time calculations.
Just for reference, the rules are:
- A year is a leap year if it is divisible by 4,
- unless it is divisible by 100, then it's not a leap year,
- except when it's divisible by 400, then it IS a leap year.
At least these are the rules as of now (2024), this may or may not change in the next few centuries, depending on long-term IERS measurements. You know, the nice people with the nice atomic clocks that release the twice-yearly update to Bulletin C to say if we're going to have to deal with a leap second at the end of the period.
If you think leap years are a pain the buttocks, what do you think the average program does when a minute suddenly has 61 seconds...
| [reply] |
I remember dealing with the Y2K bug back in 1985.
I was working at a stock brokers and 15-year bonds were maturing the same day.
Some examples (in the spoiler) in case the reasoning isn't immediately obvious:
Using YYMMDD formatting in the evening batch processing:
-
(bond purchased on 31-12-1984)
Was 841231 (processing date) >= 991231 (maturity date)?
No, bond hasn't matured so no payout.
-
(bond purchased on 31-12-1984)
Was 991231 (processing date) >= 991231 (maturity date)?
Yes, bond has matured so pay client.
-
(bond purchased the next day on 01-01-1985)
Was 850101 (processing date) >= 000101 (maturity date)?
Yes, bond has matured so pay client.
Oops!
Anyway, I recall implementing the "4/100/400 leap year rule",
along with changing YYMMDD to YYYYMMDD, as part of the fix.
| [reply] |