1415202 - Always use the equivalent year when determining the time zone offset and name in PRMJ_FormatTime

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[André Bargull [:anba]]

:jandem and :arai encountered test failures when running jstests locally on Macs [1]. It looks like at least one of mktime, localtime_r, or strftime doesn't work as expected for years >= 2038, but interestingly we don't seem to hit this issue on Mac CI builds.
Given that PRMJ_FormatTime is nowadays only used to get the time zone name or when ICU is explicitly disabled, we can probably safely fix this issue by always using the "equivalent year" when we retrieve tm_gmtoff and tm_zone [2].

[1] https://mozilla.logbot.info/jsapi/20171107#c13815880
[2] https://searchfox.org/mozilla-central/rev/7e090b227f7a0ec44d4ded604823d48823158c51/js/src/vm/Time.cpp#308,317,325-326

Comment 1

[André Bargull [:anba]]

Attachment: bug1415202.patch

f? for :jandam and/or :arai to validate this patch fixes the local jstests failures on MacOS.

With this change PRMJ_FormatTime always uses the equivalent year to compute the time zone offset and name. This should ensure that the underlying libc implementation doesn't perform any year 2038 workaround on its own (which I guess led to the local issues on MacOS). This change also ensures that time zone name always matches the time zone offset in Date.prototype.to(Time)String which wasn't necessarily the case before this patch (only applies for historical dates, see below).


TZ=Europe/London
Test: new Date(0).toString()
Before:  "Thu Jan 01 1970 01:00:00 GMT+0100 (BST)"
After:   "Thu Jan 01 1970 01:00:00 GMT+0100 (BST)"
Correct: "Thu Jan 01 1970 01:00:00 GMT+0100 (BST)"
Note: No change.


TZ=Europe/London
Test: new Date(-1000).toString()
Before:  "Wed Dec 31 1969 23:59:59 GMT+0000 (BST)" <-- name doesn't match offset
After:   "Wed Dec 31 1969 23:59:59 GMT+0000 (GMT)"
Correct: "Thu Jan 01 1970 00:59:59 GMT+0100 (BST)"


TZ=Europe/Amsterdam
Test: new Date(1938,0,1).toString()
Before:  "Sat Jan 01 1938 00:00:00 GMT+0100 (NET)" <-- name doesn't match offset
After:   "Sat Jan 01 1938 00:00:00 GMT+0100 (CET)"
Correct: "Sat Jan 01 1938 00:00:00 GMT+0020 (+0020)"


TZ=Asia/Tokyo
Test: new Date(1950,6,1).toString()
Before:  "Sat Jul 01 1950 00:00:00 GMT+0900 (JDT)" <-- name doesn't match offset
After:   "Sat Jul 01 1950 00:00:00 GMT+0900 (JST)"
Correct: "Sat Jul 01 1950 00:00:00 GMT+1000 (JDT)"

Comment 2

[Tooru Fujisawa [:arai]]

yes, it fixes the failure of ecma_6/Date/time-zone-2038-pst.js

Comment 3

[Jan de Mooij [:jandem]]

Comment on attachment 8926363 [details] [diff] [review]
bug1415202.patch

Yes this fixes the test failure for me too.

Comment 4

[Jan de Mooij [:jandem]]

This test no longer fails for me on OS X, maybe because DST ended? If so it would be good to fix before that starts again...

Comment 5

[André Bargull [:anba]]

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1b08118f4d252a34678274c2e43b0d1fae2f20c7

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ce9f1466ec78
Always use the equivalent year to determine the time zone offset and name. r=Waldo

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/ce9f1466ec78