Closed Bug 1818103 Opened 2 years ago Closed 2 years ago

toLocaleString("en-CA") is now incorrect because of Unicode CLDR issue 16399

Categories

(Core :: JavaScript: Internationalization API, defect, P4)

Firefox 111
defect

Tracking

()

VERIFIED FIXED
113 Branch
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)

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.

Summary: toLocaleString("en-CA") is now incorrect because of Unicode CLDR bug #16399 → toLocaleString("en-CA") is now incorrect because of Unicode CLDR bug 16399
Summary: toLocaleString("en-CA") is now incorrect because of Unicode CLDR bug 16399 → toLocaleString("en-CA") is now incorrect because of Unicode CLDR issue 16399

sorry sample js code could better be:

[ new Date(2023,0,3).toLocaleString("en-CA") , new Date(2023,0,3).toLocaleString("fr-CA") ]

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.

Component: Untriaged → JavaScript: Internationalization API
Product: Firefox → Core
Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P4
Duplicate of this bug: 1819353
Duplicate of this bug: 1820377
See Also: → 1820375

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?

Flags: needinfo?(andrebargull)

chromium has reverted to ICU 71 in their 112
CLDR have also reverted in CLDR 43 and will investigate further

Keywords: regression
Regressed by: 1792775

Set release status flags based on info from the regressing bug 1792775

(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:

(*) 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).

Flags: needinfo?(andrebargull)

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?

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

Set release status flags based on info from the regressing bug 1792775

Could you mark bug 1805995 as a duplicate of this as well.

Flags: needinfo?(zibi)
Duplicate of this bug: 1805995
Flags: needinfo?(zibi)
Duplicate of this bug: 1820375
Assignee: nobody → andrebargull
Status: NEW → ASSIGNED
Pushed by andre.bargull@gmail.com: https://hg.mozilla.org/integration/autoland/rev/e4780e5614f3 Revert date format for en-CA. r=platform-i18n-reviewers,jfkthame

The severity field for this bug is set to S3. However, the following bug duplicate has higher severity:

:anba, could you consider increasing the severity of this bug to S2?

For more information, please visit auto_nag documentation.

Flags: needinfo?(andrebargull)
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 113 Branch
Severity: S3 → S2
Flags: needinfo?(andrebargull)

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
Attachment #9324624 - Flags: approval-mozilla-beta?

Comment on attachment 9324624 [details]
Bug 1818103: Revert date format for en-CA. r=#platform-i18n-reviewers!

Approved for 112.0b8

Attachment #9324624 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Verified as fixed in our latest Beta 112.0b8 as well as our latest Nightly 113.0a1 (2023-03-27)

Status: RESOLVED → VERIFIED
See Also: 1820375
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: