The 100-Year Bug Microsoft Never Fixed: How Excel Still Carries a Mistake from the 1980s
What if one of your go-to apps had a known flaw that’s lasted for decades, simply because the original mistake wasn’t theirs? It might sound unbelievable, but that’s precisely the case with Microsoft Excel.
Despite being a cornerstone of modern productivity software, Excel still carries a bug from the 1980s that’s never been corrected. And it all started with a spreadsheet program from the 1980s called Lotus 1–2–3.
The Hidden Backbone of Spreadsheets: Date Systems
To understand this bug, we need to take a quick look at how spreadsheets like Excel handle dates. When you enter a date, such as January 1, 2025, into Excel, it is not stored as a typical calendar date. Internally, Excel converts it into a serial number, which represents the number of days that have elapsed since a fixed starting date.
But here’s where things get tricky. Excel has two different starting points, also called date systems:
- The 1900 Date System (used by default in Windows):
- Starts counting from January 1, 1900.
- So, January 1, 1900 = 1, January 2, 1900 = 2, and so on.
2. The 1904 Date System (used by default on older Mac versions):
- Starts counting from January 1, 1904.
- So, January 1, 1904 = 1, January 2, 1904 = 2, and so on.
This means if two people are using different systems, the same number could represent two completely different dates, causing errors when files are shared across platforms. However, the real twist is that the 1900 system has a built-in error, which has been present from the beginning.
The 1900 Leap Year That Never Happened
According to the rules of the calendar, 1900 was not a leap year. (Leap years happen every 4 years, except for years divisible by 100 unless they are also divisible by 400.) However, in Excel’s 1900 system, February 29, 1900, exists, even though it never actually occurred in real life. This fake date shifts all subsequent dates by one extra day.
Why would Microsoft include a date that never existed? Because Lotus 1–2–3 did it first.
Microsoft Copied the Mistake — On Purpose
In the 1980s, Lotus 1–2–3 was the reigning champion of spreadsheet software. When Microsoft created Excel, it aimed to ensure that users could easily transition without losing their existing spreadsheets. So, instead of fixing the leap year bug, Microsoft copied it exactly, for compatibility. They even documented it internally, knowing it was a mistake. And here’s the kicker: Microsoft never removed it.
Why It Still Matters Today
You might think this is just a nerdy piece of spreadsheet trivia. But it still causes real problems:
- Files shared between Mac and Windows users can display dates that are 4 years off due to the different start dates (1900 vs. 1904).
- Programs and scripts that rely on exact date calculations can break.
- Users become confused when Excel displays or calculates incorrect dates without explanation.
- The bug remains in every version of Excel to this day.
Why Not Just Fix It?
The simple answer: backward compatibility.
If Microsoft were to fix the error now, millions of existing spreadsheets would display incorrect dates. That would break accounting records, contracts, and business systems worldwide. So the bug lives on — a kind of digital fossil from the early days of computing.
Conclusion: A Mistake That Became a Standard
It’s fascinating (and somewhat ironic) that Microsoft Excel is built on a known error from a long-dead rival software. This is a rare case in tech where a mistake was intentionally preserved, all in the name of compatibility.
So the next time you enter a date in Excel, just remember: there’s a little bit of 1980s history and a ghost leap day from 1900, hidden inside every cell.