Fix basedate calculation #2683

Open
ivan-trusov wants to merge 6 commits from ivan-trusov/fix-basedate into master
ivan-trusov commented 2022-05-13 08:09:24 +00:00 (Migrated from github.com)

Current method of numdate/datenum calculation works incorrectly for timezones that are equal nowadays but were different in the past (e.g. Europe/Minsk and Europe/Moscow). Suggested method bypasses this issue by initializing basedate to UTC 1899-11-30 00:00:00 and slightly modifying TZ offsets handling.

Current method of numdate/datenum calculation works incorrectly for timezones that are equal nowadays but were different in the past (e.g. Europe/Minsk and Europe/Moscow). Suggested method bypasses this issue by initializing basedate to UTC 1899-11-30 00:00:00 and slightly modifying TZ offsets handling.
Fil (Migrated from github.com) reviewed 2022-05-31 14:21:30 +00:00
ivan-trusov (Migrated from github.com) reviewed 2022-05-31 14:28:35 +00:00
SheetJSDev commented 2022-06-02 00:40:17 +00:00 (Migrated from github.com)

We'll revisit dates later this month. Please don't merge with latest, as the actual commits can be cherrypicked as needed.

Given the 4-year old V8/NodeJS/Chrome timezone bug and the declining prospects of a real fix to V8, we'll have to adjust. Would it make more sense to anchor to a date that does not suffer from the bug? Looking at the tz database, the last timezone to align to integral minutes is Africa/Monrovia, which shifted on 1972-01-07 (date code 26305 in the 1900 date system)

We'll revisit dates later this month. Please don't merge with latest, as the actual commits can be cherrypicked as needed. Given the [4-year old V8/NodeJS/Chrome timezone bug](https://bugs.chromium.org/p/v8/issues/detail?id=7863) and the declining prospects of a real fix to V8, we'll have to adjust. Would it make more sense to anchor to a date that does not suffer from the bug? Looking at the tz database, the last timezone to align to integral minutes is `Africa/Monrovia`, which shifted on 1972-01-07 (date code 26305 in the 1900 date system)
ivan-trusov commented 2022-06-02 10:43:57 +00:00 (Migrated from github.com)

Please don't merge with latest, as the actual commits can be cherrypicked as needed.

My fail. Apologize.
I slightly refactored numdate()/datenum() functions. AFAIK OADate must be treated as it has no TZ or DST issues ("always in local TZ"), so I suggest to do all calculations in UTC and at the very end de-adjust TZ offset forcibly added by JS engine

> Please don't merge with latest, as the actual commits can be cherrypicked as needed. My fail. Apologize. I slightly refactored numdate()/datenum() functions. AFAIK OADate must be treated as it has no TZ or DST issues ("always in local TZ"), so I suggest to do all calculations in UTC and at the very end de-adjust TZ offset forcibly added by JS engine
This pull request has changes conflicting with the target branch.
  • xlsx.js

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin ivan-trusov/fix-basedate:ivan-trusov/fix-basedate
git checkout ivan-trusov/fix-basedate

Merge

Merge the changes and update on Gitea.
git checkout master
git merge --no-ff ivan-trusov/fix-basedate
git checkout master
git merge --ff-only ivan-trusov/fix-basedate
git checkout ivan-trusov/fix-basedate
git rebase master
git checkout master
git merge --no-ff ivan-trusov/fix-basedate
git checkout master
git merge --squash ivan-trusov/fix-basedate
git checkout master
git merge --ff-only ivan-trusov/fix-basedate
git checkout master
git merge ivan-trusov/fix-basedate
git push origin master
Sign in to join this conversation.
No description provided.