“The Lotus guys probably figured it didn’t matter to be wrong”: Excel thinks 1900 was a leap year because of a small shortcut taken in the ’80s — I’ll think of this next time I want to cut corners
Excel contains a famous bug where it incorrectly recognizes February 29, 1900 as a valid date, despite 1900 not being a leap year mathematically. This quirk originated in the 1980s when Microsoft was competing with Lotus 1-2-3, which contained the same error. Rather than fix the bug, Excel developers chose to replicate it intentionally to maintain compatibility with Lotus spreadsheets, allowing users to switch between the two applications without data inconsistencies.
The bug has persisted for over four decades as a consequence of this early compatibility decision. It serves as a notable cautionary tale in software development about the long-term costs of cutting corners and prioritizing short-term compatibility over technical correctness. Once established in a widely-used application, such decisions become nearly impossible to reverse without breaking existing spreadsheets and workflows that may rely on the behavior, no matter how technically incorrect it is.