Because most users do not use dates before March 1, 1900, this problem is rare

There are really only three contenders for the most popular spreadsheet software: VisiCalc, the first computer spreadsheet and a system-seller for some home computers in the late 1970s, Lotus 1-2-3 dominating early PCs in the 1980s, and then Microsoft Excel (preceded very briefly by Multiplan). Excel dominated the market since the 1990s – so long it’s easy to assume it has always been there, but even hiding within Excel are some quirks of its predecessors.

One of them is documented in an official Microsoft Excel troubleshooting document:

When Lotus 1-2-3 was first released, the program assumed that the year 1900 was a leap year, even though it actually was not a leap year. This made it easier for the program to handle leap years and caused no harm to almost all date calculations in Lotus 1-2-3.

When Microsoft Multiplan and Microsoft Excel were released, they also assumed that 1900 was a leap year. This assumption allowed Microsoft Multiplan and Microsoft Excel to use the same serial date system used by Lotus 1-2-3 and provide greater compatibility with Lotus 1-2-3. Treating 1900 as a leap year also made it easier for users to move worksheets from one program to the other.

Yes, even in today’s version of Excel, you can easily get to Feb 29, 1900 – a date that never existed:

I find what follows in the same doc really funny, as you can sense perhaps a frustration of someone needing to answer this over and over again, or held to blame for the decision that wasn’t even theirs to begin with:

Although it is technically possible to correct this behavior so that current versions of Microsoft Excel do not assume that 1900 is a leap year, the disadvantages of doing so outweigh the advantages.

If this behavior were to be corrected, many problems would arise, including:

If the behavior remains uncorrected, only one problem occurs:

But I also appreciate the details of what is a great example of bug-for-bug compatibility.