1266424 - Update internal timezone database to version 2016j

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[Stefan Sitter [:ssitter]]

The 2016d release of tz code and data is available:
https://mm.icann.org/pipermail/tz-announce/2016-April/000038.html

Comment 1

[Stefan Sitter [:ssitter]]

The 2016e release of tz code and data is available:
https://mm.icann.org/pipermail/tz-announce/2016-June/000039.html

Comment 2

[Stefan Sitter [:ssitter]]

The 2016f release of tz code and data is available:
https://mm.icann.org/pipermail/tz-announce/2016-July/000040.html

Comment 3

[Martin Schröder [:mschroeder]]

The 2016g release of tz code and data is available:
https://mm.icann.org/pipermail/tz-announce/2016-September/000041.html

Comment 4

[Martin Schröder [:mschroeder]]

The 2016h release of tz code and data is available:
https://mm.icann.org/pipermail/tz-announce/2016-October/000042.html

Comment 5

[Stefan Sitter [:ssitter]]

The 2016i release of tz code and data is available:
https://mm.icann.org/pipermail/tz-announce/2016-November/000043.html

This will have impact on localization due to the new timezones.

Comment 6

[[:MakeMyDay]]

Can you prepare a patch for this? Merge date is on Monday, so landing this before would be great.

Comment 7

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Update to 2016i

Ah yes, I should have gotten around to this. Given the timezone strings are in the filter.py ignore rules, I think it would be ok to do late-l10n for this.

Comment 8

[[:MakeMyDay]]

Comment on attachment 8811206 [details] [diff] [review]
Update to 2016i

Review of attachment 8811206 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. Even though timezone names are not required to be localized, many locales do this. That said, regarding the landing on Autora, I propose do land all late l10n strings in a coordinated way. See https://bugzilla.mozilla.org/show_bug.cgi?id=1312113#c5

As this just missed the latest ESR release, we would have time for backporting to Beta and ESR anyway, but you maybe can already grant the approvals.

Comment 9

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Update to 2016j

2016j was just released with more strings

Comment 10

[[:MakeMyDay]]

https://hg.mozilla.org/comm-central/rev/cd64861e22c692f2237e60b141b113ec0a8d0665
https://hg.mozilla.org/comm-central/rev/c69a1269ca8d7836a24f57b11386a0d186f1b812

Comment 11

[[:MakeMyDay]]

Comment on attachment 8811206 [details] [diff] [review]
Update to 2016i

a+ from Philipp on irc for both patches

Comment 12

[Jorg K (CEST = GMT+2)]

Aurora (Thunderbird 52 / Lightning 5.4)
https://hg.mozilla.org/releases/comm-aurora/rev/1f54af80506e
https://hg.mozilla.org/releases/comm-aurora/rev/ef6c6884a78f

Comment 15

[Stefan Sitter [:ssitter]]

Users are affected by the out-of-date and incorrect timezone information in Lightning 4.7 releases. Would it be possible to port the changes back to comm-release?

Comment 16

[Oguz YILMAZ]

Turkish time problem exist current community version TB 45.7.1, Lightning 4.7.7.1. The problem is well defined in the bug 1335328 which is closed.

Comment 17

[Philipp Kewisch [:Fallen][📱📆]]

(In reply to Stefan Sitter from comment #15)
> Users are affected by the out-of-date and incorrect timezone information in
> Lightning 4.7 releases. Would it be possible to port the changes back to
> comm-release?

Lightning 5.4 is about to be released, so I don't think it is worth doing now (nor a month ago when you asked). We should work on a mechanism to do Timezone updates quicker though. I guess the only chance we have is to release en-US only, or wait 12 weeks and then backport the aurora strings to release manually.