Repository navigation
ToLocaleDateString inconsistent/wrong output locale to "en-CA" #45945
Description
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
Activity
[-]ToLocaleDateString inconsistent output locale to "en-CA" [/-][+]ToLocaleDateString inconsistent/wrong output locale to "en-CA" [/+]bnoordhuis commentedon Dec 23, 2022
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 commentedon Jan 10, 2023
@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 commentedon Jan 10, 2023
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
yMddate format (warning: big file)It's the removal of the
<dateFormatItem id="yMd">y-MM-dd</dateFormatItem>tag fromcommon/main/en_CA.xmlin commit unicode-org/cldr@0529d07 but you probably can't see it in GH's web UI, the diff is too big.keepitterron commentedon Jan 10, 2023
thank you @bnoordhuis for taking the time to pull those links, super appreciated! 🙏
i'll dig in, fascinating stuff!
srl295 commentedon Jan 14, 2023
And removing that line, per vetter feedback, leaving the pattern for
yMdatM/d/ywas a deliberate change.Working as designed, for v8, Node, ICU, CLDR process, etc.
vezaynk commentedon Feb 25, 2023
What is going on here? Canada specifies yyyy-mm-dd. The new implementation is incorrect:
Is the issue being tracked somewhere?
srl295 commentedon Feb 25, 2023
It's being discussed upstream in CLDR at https://unicode-org.atlassian.net/browse/CLDR-16399
A change, not necessarily a regression.
SantiagoDePolonia commentedon Apr 26, 2023
You can use
date.toLocaleString("en-US").replace(/\s/g, " ")to fix the hydration error.srl295 commentedon Apr 26, 2023
reverted the change in CLDR v43 (ICU 73.1)
SantiagoDePolonia commentedon Apr 26, 2023
Therefore it should be changed in a upcoming node version.