Update timezones to 2021a
Categories
(Calendar :: Internal Components, task)
Tracking
(thunderbird_esr78 wontfix)
Tracking | Status | |
---|---|---|
thunderbird_esr78 | --- | wontfix |
People
(Reporter: mschroeder, Assigned: darktrojan)
Details
Attachments
(1 file)
48 bytes,
text/x-phabricator-request
|
wsmwk
:
approval-comm-beta-
|
Details | Review |
Assignee | ||
Comment 1•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/29ff2df721b2
Update timezones to 2021a. r=mkmelin
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 3•3 years ago
|
||
I guess we should uplift?
Assignee | ||
Comment 4•3 years ago
|
||
Comment on attachment 9194593 [details]
Bug 1684021 - Update timezones to 2021a. r?Fallen
[Approval Request Comment]
Just a time zones update.
Comment 5•3 years ago
|
||
Comment on attachment 9194593 [details]
Bug 1684021 - Update timezones to 2021a. r?Fallen
[Triage Comment]
Sorry, we missed doing the next 89 beta, so this will appear in beta 90
Comment 6•3 years ago
|
||
Needed for 78?
Updated•3 years ago
|
I might be missing something big, like actually understanding. But I looks to me like this update overwrote the update in bug 1515937 to remove DST from Brazil and replaced it in the file zones.json around line 1116.
https://searchfox.org/comm-central/source/calendar/timezones/zones.json
Support topic https://support.mozilla.org/en-US/questions/1366544
Looking further at this, it looks like TZURL may not have updated to the latest release that was supported to fix the issue. https://github.com/benfortuna/tzurl/issues/34
I assume Bug 1158733 has made all this obsolete, but a fix for ESR is required unless there is an uplift of Bug 1158733 to ESR.
Assignee | ||
Comment 9•3 years ago
|
||
We have time zone information for all dates between 2018 and 2024. All dates before 2018 are in the same offset as at 2018-01-01. All dates after that are in the same offset as the last information we have. (And yes, it's probably time to move the threshold dates forward a few years again.)
Here's our definition of America/Sao_Paulo:
BEGIN:DAYLIGHT
TZOFFSETFROM:-0300
TZOFFSETTO:-0200
TZNAME:-02
DTSTART:19700101T000000
RDATE:19700101T000000
RDATE:20181104T000000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0200
TZOFFSETTO:-0300
TZNAME:-03
DTSTART:20180218T000000
RDATE:20180218T000000
RDATE:20190217T000000
END:STANDARD
Brazil was in DST at 2018-01-01. Then it left DST on 2018-02-18, went back on 2018-11-04, then left again on 2019-02-17. All dates after that are considered to be in standard time.
We add all of this zone information to things exported as ICS, regardless of whether it applies to the dates in question, because it's easier than messing around with the definition, and clients will just ignore the irrelevant information. So to answer the support question about getting rid of it from iCal files, you don't remove it, it's not wrong, just irrelevant.
Description
•