Closed Bug 1684021 Opened 4 years ago Closed 4 years ago

Update timezones to 2021a

Categories

(Calendar :: Internal Components, task)

Tracking

(thunderbird_esr78 wontfix)

RESOLVED FIXED
89 Branch
Tracking Status
thunderbird_esr78 --- wontfix

People

(Reporter: mschroeder, Assigned: darktrojan)

Details

Attachments

(1 file)

Assignee: nobody → geoff
Status: NEW → ASSIGNED
Attachment #9194593 - Attachment description: Bug 1684021 - Update timezones to 2020e. r?Fallen → Bug 1684021 - Update timezones to 2021a. r?Fallen
Summary: Update timezones to 2020e → Update timezones to 2021a

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/29ff2df721b2
Update timezones to 2021a. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch

I guess we should uplift?

Comment on attachment 9194593 [details]
Bug 1684021 - Update timezones to 2021a. r?Fallen

[Approval Request Comment]
Just a time zones update.

Attachment #9194593 - Flags: approval-comm-beta?

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

Attachment #9194593 - Flags: approval-comm-beta? → approval-comm-beta-

Needed for 78?

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.

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.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: