Closed Bug 1430761 Opened 2 years ago Closed 2 years ago

Update to tzdata2018c


(Core :: JavaScript: Internationalization API, defect, P1)




Tracking Status
firefox-esr52 --- fixed
firefox58 --- wontfix
firefox59 --- fixed
firefox60 --- fixed


(Reporter: anba, Assigned: anba)



(3 files, 1 obsolete file)

tzdata2018a will probably be released in the next few days (it's already tagged at, but not yet available at and 

>  São Tomé and Príncipe switched from +00 to +01.
>  Brazil's DST will now start on November's first Sunday.
>  Ireland's standard time is now in the summer, not the winter.

The Irland change [1] definitely needs to be tested, because I'm not sure every component works correctly with the notion of a negative DST in winter.

Update title to refer to tzdata2018b (tzdata2018b == tzdata2018a + build fix for tzdata).
Summary: Update to tzdata2018a → Update to tzdata2018b
(In reply to André Bargull [:anba] from comment #0)
> The Irland change [1] definitely needs to be tested, because I'm not sure
> every component works correctly with the notion of a negative DST in winter.

The new release is tzdata2018c which no longer contains the problematic Ireland changes.
Summary: Update to tzdata2018b → Update to tzdata2018c
Attached patch bug1430761.patch (obsolete) — Splinter Review
Generated with:
  cd intl
  ./ -e $ICU60_BUILD_DIR/bin/icupkg 2018c
  cd ../js/src/builtin
  ./ tzdata

I've verified the Africa/Sao_Tome and the Brazil changes are correctly applied:

js> new Intl.DateTimeFormat(undefined, {timeZone:"Africa/Sao_Tome", timeZoneName: "short"}).format()
"26.1.2018, GMT"
js> new Intl.DateTimeFormat(undefined, {timeZone:"America/Sao_Paulo", timeZoneName: "short"}).format(new Date(2018, 11-1, 1))
"1.11.2018, GMT-2"

js> new Intl.DateTimeFormat(undefined, {timeZone:"Africa/Sao_Tome", timeZoneName: "short"}).format()
"26.1.2018, GMT+1"
s> new Intl.DateTimeFormat(undefined, {timeZone:"America/Sao_Paulo", timeZoneName: "short"}).format(new Date(2018, 11-1, 1))
"1.11.2018, GMT-3"
Assignee: nobody → andrebargull
Attachment #8945752 - Flags: review?(jwalden+bmo)
Comment on attachment 8945752 [details] [diff] [review]

Review of attachment 8945752 [details] [diff] [review]:

Might need slight tweaking for the generated-file moves, maybe, fine otherwise.
Attachment #8945752 - Flags: review?(jwalden+bmo) → review+
Attached patch bug1430761.patchSplinter Review
Rebased to apply cleanly on current inbound. Carrying r+.
Attachment #8945752 - Attachment is obsolete: true
Attachment #8947434 - Flags: review+
Backport for ESR52.
Attachment #8947452 - Flags: review?(jwalden+bmo)
Backport for beta.
Attachment #8947453 - Flags: review?(jwalden+bmo)
Attachment #8947452 - Flags: review?(jwalden+bmo) → review+
Attachment #8947453 - Flags: review?(jwalden+bmo) → review+
Pushed by
Update tzdata in ICU data files to 2018c. r=Waldo
Keywords: checkin-needed
Priority: -- → P1
Comment on attachment 8947453 [details] [diff] [review]

Approval Request Comment
[Feature/Bug causing the regression]: N/A

[User impact if declined]:
Wrong or inconsistent time zone data when calling methods from Intl.DateTimeFormat or methods internally using Intl.DateTimeFormat (that means Date.prototype.toLocale(Date|Time)String()). Inconsistencies are possible when the OS already uses the current tzdata release (tzdata 2018c), but our internal ICU version still uses tzdata 2017c. 
Based on the release notes for tzdata 2018c (, the update is of special interest for users in São Tomé and Príncipe (time zone switched from +00 to +01 on Jan 1 2018) and Brazil (starting this year, DST now begins on the first Sunday of November).

[Is this code covered by automated tests?]:

[Has the fix been verified in Nightly?]:

[Needs manual test from QE? If yes, steps to reproduce]: 

[List of other uplifts needed for the feature/fix]:

[Is the change risky?]:

[Why is the change risky/not risky?]:
It only updates time zone data files.

[String changes made/needed]:
Attachment #8947453 - Flags: approval-mozilla-beta?
Comment on attachment 8947452 [details] [diff] [review]

[Approval Request Comment]

If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: 
See comment #12.

Fix Landed on Version:
Firefox 60; Firefox 59 see comment #12.

Risk to taking this patch (and alternatives if risky): 
See comment #12.

String or UUID changes made by this patch: 
Attachment #8947452 - Flags: approval-mozilla-esr52?
Comment on attachment 8947452 [details] [diff] [review]

New updates for time zone changes for 2018. Let's get this into esr for 52.7.
Attachment #8947452 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52+
Comment on attachment 8947453 [details] [diff] [review]

Time zone fixes should be in the next beta, 59.0b9.
Attachment #8947453 - Flags: superreview+
Attachment #8947453 - Flags: approval-mozilla-beta?
Attachment #8947453 - Flags: approval-mozilla-beta+
Why was this marked leave-open?
Flags: needinfo?(andrebargull)
I marked it as leave-open before I requested the Beta and ESR uplifts, so it doesn't get closed when the patch is merged into central. And I haven't yet removed the "leave-open" marker, because it seems like that the ESR patch still needs to land.
Flags: needinfo?(andrebargull)
SOP is to use bug resolution to track landing on m-c and status flags for branch uplifts :)
Closed: 2 years ago
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
You need to log in before you can comment on or make changes to this bug.