Excel still thinks 1900 had a February 29 — and it’s on purpose

The bug

Excel will happily accept February 29, 1900, as a real date. Odd? Yes. Dangerous? Sometimes. The program's internal date system treats days as serial numbers starting in 1900, but retains a quirk: it counts 1900 as a leap year even though, by the Gregorian calendar rules, it was not. The result is a phantom day that can throw off date math for anyone poking at pre-1900 calendars or cross-checking ancient spreadsheets.

Why it persists

So why not just fix it? Because of compatibility. It has been reported that a Microsoft explanation reads: "Although it is technically possible to correct this behavior, the disadvantages of doing so outweigh the advantages." In plain English: change the rule and you break millions of existing spreadsheets that quietly rely on the wrong serial numbering. The mistake originates in Lotus 1-2-3; Excel copied it to avoid upsetting users back when spreadsheets were becoming the backbone of business workflows. Legacy, meet inertia.

Files, firms and workflows are the emotional center of this story. One small “correction” ripples into mismatched reports, recalculated dashboards and a lot of explaining to do. Want a rule of thumb? If you share a workbook that mixes date systems, expect headaches. Workarounds exist — like using the 1904 date system or adding manual offsets — but they're clunky band-aids, not elegant solutions.

This is a textbook trade-off: precision now versus stability forever. It’s also a reminder that software history matters. Sometimes the polite thing to do is not the correct thing — and software vendors, stuck between accuracy and the havoc of change, often choose the polite route. Legacy wins again.

Sources: reddit