Wrong day number for dates before March 1 1900. #2942
Labels
No Label
DBF
Dates
Defined Names
Features
Formula
HTML
Images
Infrastructure
Integration
International
ODS
Operations
Performance
PivotTables
Pro
Protection
Read Bug
SSF
SYLK
Style
Write Bug
good first issue
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sheetjs/sheetjs#2942
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Excel (inconrrectly) considers 1900 to be a leap year (https://learn.microsoft.com/en-us/office/troubleshoot/excel/wrongly-assumes-1900-is-leap-year). datenum function is blindly adding an extra day to account for Feb 29 1900 to all dates, making the result wrong for dates earlier than Mar 1 1900. For example, calling the datenum function with the date Jan 1 1900 returns 2 instead of 1 (from https://learn.microsoft.com/en-us/office/troubleshoot/excel/1900-and-1904-date-system, "When you enter a date, the date is converted into a serial number that represents the number of elapsed days starting with 1 for January 1, 1900.").
There are corrections for the 1900 bug throughout the library, from the parsing and writing codecs to the SSF number formatting library. If you can share a problematic file or a situation where the date is off by a day, we can take a closer look and reopen the issue.
Actually I fixed this by copying the same date treatment used in datenum_local, along with another bug (#2644) but I'm having trouble pushing the commits to either a branch or fork of my own to do the PR.
The referenced bug is related to a V8 bug (https://bugs.chromium.org/p/v8/issues/detail?id=7863) that we plan on addressing in 0.20
Well, I found that it can be solved idependently of the V8 bug.
If I understood correctly, the error is introduced because the basedate time zone offset is added to dnthresh (through the getTime() function) with seconds resolution and then subtracted (through the getTimezoneOffset() function) with minutes resolution.
But there's a catch: the basedate is only needed to calculate the day number (integer part of the cell value) but not the time of day (the fractional part of the cell value).
What I did is separate the calculation of the day number from the calculation of the time of day, so the basedate time zone offset isn't used at all. Of course it involves some more math, but the result is correct.
What is the error message?
Don't worry, the error was me trying to do things I don't know about :) Like me coding in JavaScript, me writing in english or me trying to create a PR (which I hope to create in a few minutes).
I owed you the MWE you asked for in the second message. Opening the resulting file with Excel I see the "good" date as May 12 2023 (which is wrong but not the point of this bug report, it's because of #2644) and the "bad" date as Jan 2 1900 which is what this report is about. The "edge 1" and "edge 2" dates are just around Feb 29 1900 which is the turning point from wrong to right dates. Thus, all dates between Jan 1 1900 and Feb 28 1900 have an extra day added.
Regards,
juanii