Skip to content

Conversation

@ivan-trusov
Copy link

@ivan-trusov ivan-trusov commented May 13, 2022

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.

Correct numdate / datenum calculation to eliminate problems with timezones that equal nowadays but were different in the past (e.g. Europe/Minsk and Europe/Moscow)
ivan-trusov and others added 4 commits May 31, 2022 17:26
Co-authored-by: Philippe Rivière <fil@rezo.net>
Correct numdate / datenum calculation to eliminate problems with timezones that equal nowadays but were different in the past (e.g. Europe/Minsk and Europe/Moscow)
Co-authored-by: Philippe Rivière <fil@rezo.net>
@SheetJSDev
Copy link
Contributor

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)

@ivan-trusov
Copy link
Author

ivan-trusov commented Jun 2, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants