Excel incorrectly assumes that the year 1900 is a leap year

nippoo

In other "incorrect calendars" bugs, there's the Rockchip RK808 RTC, where the engineers thought that November had 31 days, needing a Linux kernel patch to this day that translates between Gregorian and Rockchip calendars (which are gradually diverging over time). Also one of my favourite kernel patch messages: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... .

darknavi

> Applies to: Microsoft Excel for Mac 2011, Excel for Microsoft 365 for Mac, Microsoft Office Excel 2003, Microsoft Office Excel 2007, Excel 2010, Excel 2013, Excel 2016

scrlk

An interesting read related to this bug from Joel Spolsky - My First BillG Review : https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...

ComputerGuru

This obligates me to share this absolute gem of date/time history folklore: https://neosmart.net/forums/threads/an-extended-history-of-t...

jdlyga

Excel is so embedded into our world that we renamed part of the human genome to prevent excel from incorrectly reading them as dates https://www.theverge.com/2020/8/6/21355674/human-genes-renam...

eviks

> If this behavior were to be corrected, many problems would arise, including: > Almost all dates in current Microsoft Excel worksheets and other documents would be decreased by one day. Unless your fix adds a day to make them stay the same?? And these silly "compatibility" excuses are begins bugs affecting more and more unsuspecting users like that gene import conversion bug affecting a quarter of all published gene research papers.

Lammy

I learned about this from my Macintosh back in The Day™, when a dead Parameter RAM battery would reset the system date to January 1st, 1904 at every boot: - https://spinsidemacintosh.neocities.org/im202#im033-001 > “The date and time setting is also copied at system startup from the clock chip into its own low-memory location. It’s stored as a number of seconds since midnight, January 1, 1904, and is updated every second. The maximum value, $FFFFFFFF, corresponds to 6:28:15 AM, February 6, 2040; after that, it wraps around to midnight, January 1, 1904.” - https://archive.org/details/mac_Macworld_Mac_Secrets_5th_Edi... - http://preserve.mactech.com/articles/develop/issue_26/minow.... - https://preterhuman.net/macstuff/qa/ops/ops23.html

jwrallie

I was developing an interface to read a .xslx file to import a table within a Qt/C++ program, and this detailed showed up in my conversions to Unix time. It turns out Claude was amazing and brought up this issue as soon as Excel was mentioned, but terrible at actually fixing up the calculations. I'd prefer using a .csv with dates already converted to Unix time, but no luck convincing the other people involved.