Error Date.toLocaleString() in node 19.0.0

[dmitriym09]

Version

19.0.0

Platform

Linux 6.0.2-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Sat, 15 Oct 2022 14:00:51 +0000 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

node

> new Date(new Date().toLocaleString('en-US'))
Invalid Date
> const s = new Date().toLocaleString('en-US')
undefined
> s.at(-3)
' '
> s.at(-3).charCodeAt()
8239
> ' '.charCodeAt()
32
> 

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

Stability

What is the expected behavior?

No response

What do you see instead?

Error Date.toLocaleString(): NARROW NO-BREAK SPACE (U+202f) without last whitespace

Additional information

Thanks for node) It`s cool)

[richardlau]

NARROW NO-BREAK SPACE sounds like it's from the CLDR 42 change in ICU 72.1
https://icu.unicode.org/download/72

In many formatting patterns, ASCII spaces are replaced with Unicode spaces (e.g., a "thin space").

except Node.js 19.0.0 doesn't ship with ICU 72.1 as that only landed on main today (#45068). Did you build Node.js yourself?

[targos]

Another possibility is that you are using a Node.js linked against your system version of ICU, and that version was updated to 72.1.

[dharesign]

Looks like a bug in v8. It's set up to handle unicode whitespace, but instead treats them as keywords. I created https://bugs.chromium.org/p/v8/issues/detail?id=13490

[srl295]

seems like user error not a bug, don't assume that Localized date format is parseable by Date.

Looking at the v8 issue, I can see where there is a coding bug on the V8 side, and I haven't looked at the spec yet.

But that said, I still disagree that the original example code here should always pass… It makes an invalid assumption about the US date format

Do not use a localized date format if you expect it to be machine readable!

[dharesign]

The spec is here: https://tc39.es/ecma262/#sec-date.parse

It specifically says:

The function first attempts to parse the String according to the format described in Date Time String Format (21.4.1.18), including expanded years. If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.

and:

However, the expression

Date.parse(x.toLocaleString())

is not required to produce the same Number value as the preceding three expressions and, in general, the value produced by this function is implementation-defined when given any String value that does not conform to the Date Time String Format (21.4.1.18)

I don't know if there's a more canonical reference for what implementation-defined strings v8 supports other than this comment in its source:
https://github.com/v8/v8/blob/5fe0aa3bc79c0a9d3ad546b79211f07105f09585/src/date/dateparser-inl.h#L23-L69

It does seem more of a coincidence that Date.parse(d.toLocaleString("en-US")) works, rather than a guarantee. But given it does work, and v8 specifically intended to delegate to icu for determining whitespace, it seems reasonable to continue the status quo.

In general though, if you want guaranteed-to-work round-trip date formatting and parsing, then you would want to use the ISO 8601 format given by toISOString().

[dharesign]

This was fixed upstream:

https://bugs.chromium.org/p/v8/issues/detail?id=13494

[srl295]

This was fixed upstream:

https://bugs.chromium.org/p/v8/issues/detail?id=13494

FWIW change LGTM