Closed Bug 1415202 Opened 4 years ago Closed 3 years ago

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

Categories

(Core :: JavaScript Engine, defect, P2)

Unspecified
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla62
Tracking Status
firefox62 --- fixed

People

(Reporter: anba, Assigned: anba)

References

Details

Attachments

(1 file)

: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
Attached patch bug1415202.patchSplinter Review
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)"
Attachment #8926363 - Flags: review?(jwalden+bmo)
Attachment #8926363 - Flags: feedback?(jdemooij)
Attachment #8926363 - Flags: feedback?(arai.unmht)
yes, it fixes the failure of ecma_6/Date/time-zone-2038-pst.js
Attachment #8926363 - Flags: feedback?(arai.unmht) → feedback+
Comment on attachment 8926363 [details] [diff] [review]
bug1415202.patch

Yes this fixes the test failure for me too.
Attachment #8926363 - Flags: feedback?(jdemooij) → feedback+
Priority: -- → P2
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...
Attachment #8926363 - Flags: review?(jwalden+bmo) → review+
Pushed by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ce9f1466ec78
Always use the equivalent year to determine the time zone offset and name. r=Waldo
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/ce9f1466ec78
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
You need to log in before you can comment on or make changes to this bug.