Microsoft Excel is Broken

And not only are they not going to fix the bug, they are also pushing for it to become a standard:

Just how thoroughly the EOOXML specification is dependent on a single vendor's applications 4 is well illustrated by the spreadsheet specification's "Date and Times" requirement (pages 3305-6). That section requires that spreadsheet dates treat the year 1900 as a leap year, which contradicts the Gregorian Calendar. This raises severe interoperability issues when interfacing with the many other developers' office suites, other office software, and development libraries that do properly implement the Gregorian Calendar. The specification straightforwardly acknowledges that this behavior is required for "legacy reasons." Indeed, it is a known bug work-around in the Microsoft Excel spreadsheet program, which would be imposed on other developers and software users by the EOOXML specification's adoption as an ISO standard, a problem discussed in more depth by Rob Weir:

"By mandating the perpetuation of this bug, we're asking for trouble. Date libraries in modern programming languages like C, C++, Java, Python, Ruby will all calculate dates correctly according to the Gregorian Calendar. So any interpretation of dates in OOXML files in these languages will be off by one day unless the author of the software adds their own workaround to their code to account for Excel's bug. Certainly some will make the “correction” properly, at their own expense. But many will not, perhaps because they did not see it deep within the 6,000 page specification."

Comments

[Peter]

Is there an update to this story? Is MS still pushing to make the bug standard? Could you send me an email to discuss this? I'd like to cite your post in a press release.

[Tristram]

This more recent article might be a better one to quote than mine (the leap year problem is mentioned on page 4):

http://www.pcpro.co.uk/realworld/127730/office-politics/page1.html