That would be a sad departure from the care that seems to have been taken with Excel to insure correctness otherwise.Īs the link provided by xor explains, the issue arose because, when Excel was introduced, Lotus 123 was the dominant spreadsheet program and Microsoft was more or less obliged to replicate the bug so as to be able to work with Lotus worksheets and vice-versa. I've kept up with upgrades for Excel 2011 and the bug persists, so I suspect Microsoft has chosen to ignore it. It's hard to believe that for an app as widely used as Excel that this is not a known flaw, although I failed to find mention of it in this forum (but I'm new here and not facile with searching). Is it present only in Excel 2011 for Mac or is it present also in any of the Windows versions as well? I don't have access to Windows machines. I'm wondering if this bug was ever fixed in Excel 2016 for Mac. But for true compatibility, wouldn't the Windows version need to harbor the same mistake? I conjecture that the problem arose when the 1900 date system for Macs was added to the 1904 system to achieve compatibility with Excel for Windows. The problem is a mistake rather than a misunderstanding because other centennial years that are not leap years are handled correctly. However, the insertion of throws off by one the date-sequence numbers used in calculations for all dates after. That one-day shift allows to be correctly designated as a Thursday, as are all subsequent dates. was actually a Monday, not a Sunday as Excel says. Further checking shows that all WEEKDAY() functions for January and February of 1900 are correspondingly off by one day, e.g. The WEEKDAY() function says was a Wednesday whereas it was that was a Wednesday. But there is no such date because 1900 was not a leap year (not an integer multiple of 400). Excel 2011 for Mac gives a date for February 29, 1900.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |