toLocaleString("en-CA") is now incorrect because of Unicode CLDR issue 16399
Categories
(Core :: JavaScript: Internationalization API, defect, P4)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox110 | --- | wontfix |
firefox111 | --- | wontfix |
firefox112 | --- | verified |
firefox113 | --- | verified |
People
(Reporter: chris.carroll, Assigned: anba)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
|
Details | Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.3 Safari/605.1.15
Steps to reproduce:
[ new Date().toLocaleString("en-CA") , new Date(2023,0,3).toLocaleString("fr-CA") ]
Actual results:
The en-CA date is formatted M/D/Y and the fr-CA date is formatted YYYY-MM-DD
Expected results:
They should both be formatted YYYY-MM-DD
References:
The bug raised at Unicode CLDR issue https://unicode-org.atlassian.net/jira/software/c/projects/CLDR/issues/CLDR-16399
includes links to the relevant Canadian Standard.
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 1•2 years ago
|
||
sorry sample js code could better be:
[ new Date(2023,0,3).toLocaleString("en-CA") , new Date(2023,0,3).toLocaleString("fr-CA") ]
Comment 2•2 years ago
|
||
I think this is the correct component for this issue, hopefully one of our devs can take a look and change it if its not the correct one.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 5•2 years ago
•
|
||
Andre, any thoughts on this given the dupes we're also seeing? I assume this was a behavior change from the ICU 72 update that shipped in 110?
Reporter | ||
Comment 6•2 years ago
|
||
chromium has reverted to ICU 71 in their 112
CLDR have also reverted in CLDR 43 and will investigate further
Comment 7•2 years ago
|
||
Set release status flags based on info from the regressing bug 1792775
Assignee | ||
Comment 8•2 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #5)
Andre, any thoughts on this given the dupes we're also seeing? I assume this was a behavior change from the ICU 72 update that shipped in 110?
Reverting to ICU 71 is a bit annoying at this point, because we'd also need to revert the update to Unicode 15. I think the two easiest solutions are either:
- Wait until ICU 73, which will include CLDR 43, where the "en-CA" formats are (partially) reverted. (*) ICU 73 probably gets released next month.
Or:
- Directly apply the corresponding CLDR changes to our local ICU copy: https://github.com/unicode-org/cldr/pull/2759
(*) https://github.com/unicode-org/cldr/pull/2759 doesn't revert the CLDR 42 changes for the generic calendar, or for interval formats (Intl.DateTimeFormat.prototype.formatRange
uses the interval format).
Comment 9•2 years ago
|
||
Cherry-picking the upstream fix makes sense to me so we can fix this more expediently and in a more upliftable way than a wholesale ICU update. Can you please do so once that fix lands?
Comment 10•2 years ago
|
||
It looks like Chrome patched their copy of ICU to fix the en-CA date format rather than reverting the entire update.
See the commit and bug:
https://chromium.googlesource.com/chromium/deps/icu/+/1e49ac26ddc712b1ab702f69023cbc57e9ae6628
https://bugs.chromium.org/p/chromium/issues/detail?id=1418727
Comment 11•2 years ago
|
||
Set release status flags based on info from the regressing bug 1792775
Updated•2 years ago
|
Comment 12•2 years ago
|
||
Could you mark bug 1805995 as a duplicate of this as well.
Updated•2 years ago
|
Assignee | ||
Comment 15•2 years ago
|
||
Revert the date format for en-CA per https://github.com/unicode-org/cldr/pull/2759.
The actual patch is based on https://github.com/unicode-org/icu/pull/2368.
Updated•2 years ago
|
Comment 16•2 years ago
|
||
Comment 17•2 years ago
|
||
The severity field for this bug is set to S3
. However, the following bug duplicate has higher severity:
- Bug 1820375: S2
:anba, could you consider increasing the severity of this bug to S2
?
For more information, please visit auto_nag documentation.
Comment 18•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Assignee | ||
Comment 19•2 years ago
|
||
Comment on attachment 9324624 [details]
Bug 1818103: Revert date format for en-CA. r=#platform-i18n-reviewers!
Beta/Release Uplift Approval Request
- User impact if declined: Date format for the locale "en-CA" doesn't match user expectation resp. doesn't match other browsers [1].
[1] Chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=1418727.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The change only modifies the date-time pattern in the ICU data file.
- String changes made/needed:
- Is Android affected?: Yes
Comment 20•2 years ago
|
||
Comment on attachment 9324624 [details]
Bug 1818103: Revert date format for en-CA. r=#platform-i18n-reviewers!
Approved for 112.0b8
Comment 21•2 years ago
|
||
bugherder uplift |
Comment 22•2 years ago
|
||
Verified as fixed in our latest Beta 112.0b8 as well as our latest Nightly 113.0a1 (2023-03-27)
Description
•