Repository navigation
Intl.DateTimeFormat('de-CH', {year, month}) outputs different separators between Node 24.13.0 and 24.13.1 #61861
Closed as not planned
Description
Version
24.13.1
Platform
Darwin N22134 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:48:41 PST 2026; root:xnu-12377.81.4~5/RELEASE_ARM64_T6041 arm64
Subsystem
No response
What steps will reproduce the bug?
Intl.DateTimeFormat produces inconsistent formatting for partial date options (year + month) between Node 24.13.0 and 24.13.1.
• Node 24.13.0 outputs '12.2021' (dot separator) as expected for de-CH.
• Node 24.13.1 outputs '12/2021' (slash separator) for the same code.
• Adding day: '2-digit' produces consistent '07.12.2021' in both versions.
This behavior change breaks SSR/client hydration in frameworks like Next.js when formatting dates for de-CH locale.
Reproduction:
// Test partial month/year formatting
console.log(
new Intl.DateTimeFormat('de-CH', { year: 'numeric', month: '2-digit' }).format(new Date("2021-12-07"))
);
// Test full date formatting
console.log(
new Intl.DateTimeFormat('de-CH', { year: 'numeric', month: '2-digit', day: '2-digit' }).format(new Date("2021-12-07"))
);How often does it reproduce? Is there a required condition?
Always
What is the expected behavior? Why is that the expected behavior?
Both Node versions should produce '12.2021' for { year, month } in de-CH locale.
Separator should follow locale conventions consistently, even for partial formats.
What do you see instead?
Node 24.13.1 outputs '12/2021'
Additional information
No response
Activity
targos commentedon Feb 17, 2026
This is an unavoidable issue. Web browsers and Node.js cannot synchronize their updates of locale data.
The format
12/2021is also already the one returned by Firefox, for example.DominikHaas-AXA commentedon Feb 20, 2026
I have a similar issue, tests are failing in currency conversion, based on 'de-CH' using the
Intl.NumberFormat('de-CH', { ... });AssertionError: expected '1'234'567.89' to be '1’234’567.89' // Object.is equality Expected: "1’234’567.89" Received: "1'234'567.89"
I can be hard to see, but the single quotes are different characters in 24.13.1 now vs before on 24.13.0.
Edit
I wonder if there is anything else affected from Intl ?
glsignal commentedon Feb 20, 2026
@DominikHaas-AXA that separator change looks like this one from the Swiss German Delta 48-47 (introduced by the recent icu update
77-1 -> 78.2), I've encountered a few changes from that delta in other locales/supplementary data as part of this patch release as well.It was a little surprising for us but I'm not familiar with how this fits in with what the node project considers when making patch/minor/major releases (could be that localised output from web platform APIs like Intl.NumberFormat aren't part of the consideration there, and like, fair enough - there's a lot of surface area there)Ah, yes, this has indeed been discussed beforeRenegade334 commentedon Feb 26, 2026
I feel like we could probably do with an explicit "locale data updates are not breaking changes" disclaimer in intl.md.
Fix issue with swiss german numeric formatter
github-actions commentedon Jul 20, 2026
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
jay123anta commentedon Aug 5, 2026
Two different changes are mixed up in this thread (checked on official docker images):
’→'grouping-separator change reported above is in this patch (ICU 77.1→78.2 / CLDR 48):12.2021→12/2021is not - official 24.13.0 already emits the slash; that changed back at ICU 68→72. A 24.13.0 built against a different ICU (e.g. Homebrew on macOS) would explain both what was seen and the hydration mismatch.I built https://github.com/jay123anta/intl-drift to catch these in CI - it snapshots ~12k Intl outputs and fails on drift; both cases here are seeded probes now.