1856428 - Intl.DateTimeFormat().resolvedOptions().timeZone invalid/changed in MacOS Sonoma

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[aeggum12]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

After upgrading to MacOS Sonoma, running Intl.DateTimeFormat().resolvedOptions().timeZone is returning "Etc/GMT+5". Prior to upgrading, it had been returning "America/Chicago", "America/Bogota", etc.

There is a similar issue reported to Chrome, where it is returning undefined [1]. Perhaps something changed with the MacOS Sonoma release causing timeZone to break? This same snippet works as expected in Safari.

[1] - https://support.google.com/chrome/thread/231926653/timezone-return-undefined?hl=en

Steps:
1 - open dev tools console
2 - Intl.DateTimeFormat().resolvedOptions().timeZone

Actual results:

Etc/GMT+5

Expected results:

America/Bogota

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Markus Stange [:mstange]]

Chromium issues:
https://bugs.chromium.org/p/chromium/issues/detail?id=1487920
https://bugs.chromium.org/p/chromium/issues/detail?id=1473422

Doesn't look like they've written a patch yet.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.

Comment 4

[Markus Stange [:mstange]]

Seems like we're using uprv_tzname to detect the system timezone: https://searchfox.org/mozilla-central/rev/630d2c45fc127a44756e3cca8cef51c35654a4b4/intl/icu/source/common/putil.cpp#1112
In the forest of ifdefs I haven't been able to find how we detect the timezone on macOS.

NSTimeZone.systemTimeZone seems like the recommended way to get this information on macOS.

Comment 5

[André Bargull [:anba]]

(In reply to Markus Stange [:mstange] from comment #4)

Seems like we're using uprv_tzname to detect the system timezone: https://searchfox.org/mozilla-central/rev/630d2c45fc127a44756e3cca8cef51c35654a4b4/intl/icu/source/common/putil.cpp#1112
In the forest of ifdefs I haven't been able to find how we detect the timezone on macOS.

Unless the TZ environment variable is set, the time zone is determined through this realpath call, which reads the target of the link file "/etc/localtime".

Maybe this is similar to bug 1848615, and the time zone files are now in a directory which can't be read because of the content sandbox? Does it work correctly when MOZ_DISABLE_CONTENT_SANDBOX=1 is used?

Comment 7

[André Bargull [:anba]]

Btw, Etc/GMT+5 is likely being returned from this fallback. This code path is taken when no alternative time zone can be determined by ICU, cf. remapShortTimeZone, which can map time zone offsets to alternative target like Europe/Athens (see also bug 1856393).

Comment 8

[andrew]

Impact of this bug is also affecting Thunderbird in Calendar

Comment 9

[Shu-yu Guo [:shu]]

To save you all some debugging time: https://unicode-org.atlassian.net/browse/ICU-22541

Comment 11

[Makoto Kato [:m_kato]]

Attachment: Bug 1856428 - MacOS Sonoma doesn't return correct timezone. r=anba

Import from https://unicode-org.atlassian.net/browse/ICU-22541
(https://github.com/unicode-org/icu/pull/2669).

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/91657cb1296c
MacOS Sonoma doesn't return correct timezone. r=anba

Comment 13

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/91657cb1296c

Comment 14

[Makoto Kato [:m_kato]]

Comment on attachment 9358461 [details]
Bug 1856428 - MacOS Sonoma doesn't return correct timezone. r=anba

Beta/Release Uplift Approval Request

• User impact if declined: When user upgrades macOS to 14, Intl.DateTimeFormat() returns different timezone string.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See https://bugzilla.mozilla.org/show_bug.cgi?id=1856428#c0
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): If timezone directory is different, use new path.
• String changes made/needed: N/A
• Is Android affected?: No

Comment 15

[Makoto Kato [:m_kato]]

Attachment: For ESR115

Comment 16

[Makoto Kato [:m_kato]]

Comment on attachment 9358604 [details] [diff] [review]
For ESR115

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Intl.DateTimeFormat().resolvedOptions().timeZone returns different result if upgrading to macOS 14.
• User impact if declined: Intl.DateTimeFormat().resolvedOptions().timeZone returns different result if upgrading to macOS 14.
• Fix Landed on Version: 120
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): If timezone directory is different, use new path.

Comment 17

[Donal Meehan [:dmeehan]]

Comment on attachment 9358461 [details]
Bug 1856428 - MacOS Sonoma doesn't return correct timezone. r=anba

Switching uplift request to release. Fx119 is now in release candidate.

Comment 18

[Donal Meehan [:dmeehan]]

Comment on attachment 9358461 [details]
Bug 1856428 - MacOS Sonoma doesn't return correct timezone. r=anba

Approved for 119.0 RC1

Comment 19

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/cac6b6540860

Comment 20

[Donal Meehan [:dmeehan]]

Comment on attachment 9358604 [details] [diff] [review]
For ESR115

Approved for 115.4esr.

Comment 21

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/7e770707fe15

Comment 22

[Makoto Kato [:m_kato]]

Attachment: Bug 1856428 - Consider incompatible breaking rules for old line segmenteri vs new line segmenter. r=TYLin

Even if ASCII, old line segmenter rules aren't compatible with UAX#14.
layout/reftests/line-breaking/markup-src-1.html runs on old segmenter prefs,
so we should use old non-breaking conditions for it with old segmenter.

Also, if word-break is break-all, we might have break opportunity for AL, NU,
IS, and QU combinations. So we should use ICU4X segmenter if break-all.

Depends on D190379

Comment 23

[Donal Meehan [:dmeehan]]

:m_kato could you consider tracking any future changes under a different bug?
This will make it easier for tracking?

Comment 24

[Makoto Kato [:m_kato]]

(In reply to Donal Meehan [:dmeehan] from comment #23)

:m_kato could you consider tracking any future changes under a different bug?
This will make it easier for tracking?

this is mistake. Thanks for notification.

Comment 25

[Alexandru Trif, Desktop Test Engineering [:atrif] [PTO 15-29 Aug, please ni? :mboldan]]

Reproduced the issue with Firefox 120.0a1 (2023-10-02) on macOS 14 Sonoma ARM by setting the Date & Time > Closest city to Bogota - Colombia and following the steps from comment 0. The result was Etc/GMT+5.
The issue is verified fixed on macOS 14 Sonoma Arm and Intel with Firefox 120.0a1 (2023-10-16), 119.0RC1 and 115.4esr. Having the time set to Bogota - Colombia will correctly display America/Bogota in the console after following the steps from comment 0. Also having the time set to Helsinki - Finland will correctly display Europe/Helsinki in the console as stated in bug 1856393#c0. Tested on macOS 12 Intel on all versions and the same results are displayed.