Excel has incorrectly assumed 1900 was a leap year for over 30 years. Microsoft knows about it, documented it, and explicitly decided "the disadvantages of fixing it outweigh the advantages." Sounds insane until you understand legacy systems - sometimes the bug is load-bearing, and fixing it would break millions of spreadsheets worldwide.

This is one of my favorite examples of technical debt in the wild. It's a perfect case study in why some bugs become features, and why engineers sometimes make the correct decision to leave broken things broken.

Here's the background: 1900 was not a leap year. Leap years occur every four years, except years divisible by 100, unless they're also divisible by 400. So 1900 wasn't a leap year, but 2000 was. Excel treats 1900 as a leap year anyway, meaning it thinks February 29, 1900 existed when it didn't.

Why? The original bug came from Lotus 1-2-3, the dominant spreadsheet before Excel. When Microsoft built Excel, they intentionally replicated the bug to maintain compatibility with Lotus spreadsheets. If Excel calculated dates correctly and Lotus didn't, any spreadsheet with dates from the early 1900s would show different values in the two programs.

So Microsoft made a pragmatic choice: ship a product that's compatible with the market leader, even if that means shipping a known bug. That made sense in the 1980s. The question is why they haven't fixed it in the 40 years since.

The answer is that the bug is now load-bearing. Millions of spreadsheets have been created over decades assuming 1900 was a leap year. If Microsoft fixes the bug, all those spreadsheets would suddenly show different dates for anything before March 1, 1900. Financial models would break. Historical data would shift. Companies relying on those spreadsheets for business-critical calculations would face data corruption.

This is what engineers mean when they talk about technical debt. The original decision made sense in context. But maintaining that decision decades later creates compounding problems. You can't fix the bug without breaking existing systems. So the bug becomes permanent.

Microsoft's official documentation on this is actually refreshingly honest. They explain the bug, acknowledge it's wrong, and explicitly state they won't fix it because the disruption would be worse than the problem. That's the right call, even though it means Excel will incorrectly handle dates from 1900 forever.

For anyone actually working with dates from the early 1900s in Excel, the workaround is simple: don't use the 1900 date system. Excel supports a 1904 date system that doesn't have this bug. But switching date systems breaks compatibility with most Excel files, so almost nobody uses it.

This bug also reveals something about how software becomes infrastructure. Excel isn't just a product Microsoft can update at will. It's embedded in critical business processes worldwide. Finance teams build models in Excel. Scientists store data in Excel. Government agencies track information in Excel. When software reaches that level of dependency, bugs become unfixable.

There's a parallel here to Y2K. That was a bug where systems stored years as two digits, so 2000 would be indistinguishable from 1900. Everyone knew it was a problem for decades. But fixing it required updating thousands of systems. The cost of fixing it eventually exceeded the cost of the original shortcuts that created the problem.

The difference is Y2K had a deadline. The world couldn't just decide to live with the bug. But the 1900 leap year bug in Excel doesn't have a forcing function. It's wrong, everyone knows it's wrong, but fixing it causes more problems than living with it. So we live with it.

I've been in meetings where engineers debate whether to fix bugs like this. The calculus is always the same: how bad is the bug versus how much would fixing it break? For bugs in widely-deployed systems, the answer is almost always "leave it alone."

What's fascinating is this bug literally doesn't affect anyone born after the 1990s working with contemporary data. If you're tracking dates from 2000 onward, Excel works fine. The bug only matters for historical data from the early 20th century. Which means its impact shrinks every year, even as fixing it becomes more disruptive.

This is the engineer's nightmare: maintaining backward compatibility when your software runs the world's businesses. You can't just fix bugs. You have to consider the downstream effects of every change. Sometimes the right decision is to document the bug, explain why it exists, and move on.

The technology is old. The bug is known. But the advantages of fixing it genuinely don't outweigh the disadvantages. That's not Microsoft being lazy - it's them understanding that sometimes the cost of being correct is too high.