Intl.DateTimeFormat().resolvedOptions().timeZone invalid/changed in MacOS Sonoma
Categories
(Core :: Internationalization, defect)
Tracking
()
People
(Reporter: aeggum12, Assigned: m_kato)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
48 bytes,
text/x-phabricator-request
|
dmeehan
:
approval-mozilla-release+
|
Details | Review |
5.44 KB,
patch
|
dmeehan
:
approval-mozilla-esr115+
|
Details | Diff | Splinter Review |
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•8 months ago
|
||
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.
Updated•8 months ago
|
Comment 2•8 months ago
|
||
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•8 months ago
|
||
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•8 months ago
|
||
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•8 months ago
|
||
(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•8 months ago
|
||
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).
Updated•8 months ago
|
Comment 9•8 months ago
|
||
To save you all some debugging time: https://unicode-org.atlassian.net/browse/ICU-22541
Updated•8 months ago
|
Assignee | ||
Comment 11•8 months ago
|
||
Updated•8 months ago
|
Comment 12•8 months ago
|
||
Pushed by m_kato@ga2.so-net.ne.jp: https://hg.mozilla.org/integration/autoland/rev/91657cb1296c MacOS Sonoma doesn't return correct timezone. r=anba
Comment 13•8 months ago
|
||
bugherder |
Assignee | ||
Comment 14•8 months ago
|
||
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
Assignee | ||
Updated•8 months ago
|
Assignee | ||
Comment 15•8 months ago
|
||
Assignee | ||
Comment 16•8 months ago
|
||
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.
Assignee | ||
Updated•8 months ago
|
Assignee | ||
Updated•8 months ago
|
Comment 17•8 months ago
|
||
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•8 months ago
|
||
Comment on attachment 9358461 [details]
Bug 1856428 - MacOS Sonoma doesn't return correct timezone. r=anba
Approved for 119.0 RC1
Comment 19•8 months ago
|
||
uplift |
https://hg.mozilla.org/releases/mozilla-release/rev/cac6b6540860
Updated•8 months ago
|
Comment 20•8 months ago
|
||
Comment on attachment 9358604 [details] [diff] [review]
For ESR115
Approved for 115.4esr.
Comment 21•8 months ago
|
||
uplift |
https://hg.mozilla.org/releases/mozilla-esr115/rev/7e770707fe15
Updated•8 months ago
|
Assignee | ||
Comment 22•8 months ago
|
||
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•8 months ago
|
||
:m_kato could you consider tracking any future changes under a different bug?
This will make it easier for tracking?
Updated•8 months ago
|
Assignee | ||
Comment 24•8 months ago
|
||
(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.
Updated•8 months ago
|
Comment 25•8 months ago
•
|
||
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.
Description
•