March 15, 2026
Leap-year LOLs, legacy chaos
Excel incorrectly assumes that the year 1900 is a leap year
Excel has believed 1900 had Feb 29 for 40 years — and users are cackling
TLDR: Excel still pretends 1900 had Feb 29 to stay compatible with old spreadsheets, and fixing it would break tons of data. Commenters are roasting legacy lock-in while sharing epic calendar bugs and the jaw-dropper that scientists renamed genes to dodge Excel—proof spreadsheets quietly shape reality.
Excel still swears 1900 had a Feb 29, and the internet is having a field day. The official story: Microsoft copied this quirk from Lotus 1-2-3 ages ago to keep spreadsheets compatible, and fixing it now would break millions of documents. The community’s reaction? A messy mix of LOL, legacy panic, and “never fix a classic” vibes.
On one side, pragmatists say it’s smart not to touch it: shifting every date by a day would be chaos, and only pre–March 1, 1900 dates get weird. On the other, skeptics call it legacy lock-in, pointing to a wall of versions darknavi rattled off that still carry the bug. The drama escalates with Joel Spolsky’s “My First BillG Review” thrown in as folklore on how decisions like this get baked into tech forever.
Then the jokes start flying. nippoo drops a wild hardware tale where November has 31 days thanks to a chip, complete with a lingering Linux kernel patch (link). ComputerGuru brings out a “time is fake” history thread (link). And everyone’s favorite mic drop: scientists literally renamed human genes so Excel wouldn’t auto-convert them to dates (link). The mood: spreadsheets run the world—and occasionally rewrite it.
Key Points
- •Excel assumes 1900 is a leap year, a behavior documented by Microsoft.
- •The assumption originates from Lotus 1-2-3 and was adopted by Multiplan and Excel for compatibility.
- •Fixing the behavior would shift most dates by one day and alter results of functions like WEEKDAY.
- •A correction would also break serial date compatibility with other programs using the same system.
- •Left uncorrected, only WEEKDAY values for dates before March 1, 1900 are wrong; other leap years are handled correctly, including 2100.