ToLocaleDateString inconsistent/wrong output locale to "en-CA"

[crowrvo]

Version

19.1.0, 19.2.0, 19.3.0

Platform

Microsoft Windows NT 10.0.22621.0 x64, Linux crowrvostation 5.15.79.1-microsoft-standard-WSL2 #1 SMP Wed Nov 23 01:01:46 UTC 2022 x86_64 GNU/Linux (Arch Linux), Linux pop-os 6.0.3-1606004-generic #20221021114922.041891946 SMP PREEMPT_DYBAMIC Sat O x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

After install node, just run a script or eval with new Date().toLocaleDateString("en-CA");

How often does it reproduce? Is there a required condition?

no conditions, just install and run

What is the expected behavior?

node 18.12.1 pop-os

19.0.0 arch linux wsl win 11

Browser output - just for comparison

What do you see instead?

node 19.1.0 wsl Arch win-11

node 19.2.0 wsl Arch win-11

node 19.3.0 wsl Arch win-11

node 19.3.0 win-11

node 19.3.0 pop-os

Additional information

even if there is no bugs, this inconsistent can break some systems that use then to date format, like me that use in a api as date range.

To get the format YYYY-MM-DD you could return to node 19.0.0 or use 'sv-SE' locale instead

Below some others locales that i'ave tested that properly works

[bnoordhuis]

Node >= v19.1.0 ships with a newer version of ICU (i18n library), that's why there's a difference.

There's no bug, it's working as expected, so I'll go ahead and close the issue but I can convert it to a discussion if you have follow-up questions.

[keepitterron]

@bnoordhuis do you have any links to find out more about where this change came from and why?
it feels weird a format changed so much and it's not consistent with the browser implementation.

I had no experience with ICU before, I might be talking nonsense.

[bnoordhuis]

Here you go, it's something of a rabbit hole:

https://icu.unicode.org/download/72 <- this is the ICU upgrade, which in turn...
https://cldr.unicode.org/index/downloads/cldr-42 - upgraded to CLDR v42, which...
https://github.com/unicode-org/cldr/blob/ac66592c93d0cb26d0b8666d3978bcab1ec889fb/common/main/en_CA.xml#L1198 - changes en-CA's yMd date format (warning: big file)

It's the removal of the <dateFormatItem id="yMd">y-MM-dd</dateFormatItem> tag from common/main/en_CA.xml in commit unicode-org/cldr@0529d07 but you probably can't see it in GH's web UI, the diff is too big.

[keepitterron]

thank you @bnoordhuis for taking the time to pull those links, super appreciated! 🙏
i'll dig in, fascinating stuff!

[srl295]

Here you go, it's something of a rabbit hole:

https://icu.unicode.org/download/72 <- this is the ICU upgrade, which in turn... https://cldr.unicode.org/index/downloads/cldr-42 - upgraded to CLDR v42, which... https://github.com/unicode-org/cldr/blob/ac66592c93d0cb26d0b8666d3978bcab1ec889fb/common/main/en_CA.xml#L1198 - changes en-CA's yMd date format (warning: big file)

It's the removal of the <dateFormatItem id="yMd">y-MM-dd</dateFormatItem> tag from common/main/en_CA.xml in commit unicode-org/cldr@0529d07 but you probably can't see it in GH's web UI, the diff is too big.

And removing that line, per vetter feedback, leaving the pattern for yMd at M/d/y was a deliberate change.

Working as designed, for v8, Node, ICU, CLDR process, etc.

[vezaynk]

What is going on here? Canada specifies yyyy-mm-dd. The new implementation is incorrect:

Date and time notation in Canada combines conventions from the United Kingdom, conventions from the United States, and conventions from France, often creating confusion.[1] The Government of Canada specifies the ISO 8601 format for all-numeric dates (YYYY-MM-DD; for example, 2023-02-23).[2] It recommends writing the time using the 24-hour clock (23:14) for maximum clarity in both Canadian English and Canadian French,[3] but also allows the 12-hour clock (11:14 p.m.) in English.[4]

Is the issue being tracked somewhere?

[srl295]

What is going on here? Canada specifies yyyy-mm-dd. The new implementation is incorrect:

Date and time notation in Canada combines conventions from the United Kingdom, conventions from the United States, and conventions from France, often creating confusion.[1] The Government of Canada specifies the ISO 8601 format for all-numeric dates (YYYY-MM-DD; for example, 2023-02-23).[2] It recommends writing the time using the 24-hour clock (23:14) for maximum clarity in both Canadian English and Canadian French,[3] but also allows the 12-hour clock (11:14 p.m.) in English.[4]

Is the issue being tracked somewhere?

It's being discussed upstream in CLDR at https://unicode-org.atlassian.net/browse/CLDR-16399

A change, not necessarily a regression.

[SantiagoDePolonia]

You can use date.toLocaleString("en-US").replace(/\s/g, " ") to fix the hydration error.

[srl295]

reverted the change in CLDR v43 (ICU 73.1)

[SantiagoDePolonia]

Therefore it should be changed in a upcoming node version.