Repository navigation
toLocaleString ignores locale and options; slash-separated dates fail to parse #9414
Description
Intl is partly ignored
(1234.5).toLocaleString("de-DE") // node "1.234,5" perry "1,234.5"
(0.5).toLocaleString("en-US",{style:"percent"}) // node "50%" perry "0.5"
(1e6).toLocaleString("en-US",{notation:"compact"}) // node "1M" perry "1,000,000"
new Date(0).toLocaleDateString("de-DE") // node "1.1.1970" perry "1/1/1970"The locale argument and the options bag are both ignored — output is always the en-US default. 28 toLocaleString sites in the cc bundle.
Slash-separated dates fail to parse
new Date("2026/09/01") // node: valid Date perry: NaN
new Date("2026/9/1") // node: valid perry: NaN
new Date("09/01/2026") // node: valid perry: NaNAll 19 other date formats tested match node. This is the implementation-defined-format branch, which node accepts and perry rejects.
Found by a differential stress-test of claude-code under perry.
Activity
fix(runtime): int32-tagged number receivers keep their toLocaleString…
fix: toLocaleString honours locale and options; accept node's numeric…
proggeramlug commentedon Sep 2, 2026
Fixed by PR #9448:
toLocaleStringdelegates locale+options to the existing ECMA-402 implementation (the arguments were amputated in runtime dispatch, not at the ABI), and the numeric slash date grammar matches node's V8 behaviour measured, not inferred. Both fixtures. Verified on main0a1c137d90with a fresh build: fixture byte-identical tonode --experimental-strip-types(stdout, stderr, and exit code).Follow-ups filed: #9449 (offsetless date-times parsed as UTC — worse than this bug), #9450 (en-IN grouping), #9451 (default field set never reaches CLDR), #9452 (Infinity.toLocaleString).
fix(date): an offsetless ISO date-TIME is LOCAL, not UTC (PerryTS#9449)
fix(date): an offsetless date-TIME is local, date-only stays UTC (#9449…