Fix basedate calculation #2683
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.
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)
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
CheckoutFrom your project repository, check out a new branch and test the changes.
MergeMerge the changes and update on Gitea.
No due date set.
No dependencies set.
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?