Fix basedate calculation #2683

2022-05-13T08:09:24Z

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.

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.