We use the Javascript function toLocaleTimeString() to parse date/times. The newest version of Chrome is returning an ASCII 226 between the seconds and the AM/PM part of the time suddenly. Edge is not having any issues nor are older versions of Chrome. 110+ has the issue and 109 or earlier does not.

For example, if the last couple of characters returned are:

00 AM

The ASCII translation of that is:

48 48 226 128 175

That 226 used to be a 32 (space).

Anyone else seeing this behavior as well?

We use the Javascript function toLocaleTimeString() to parse date/times. The newest version of Chrome is returning an ASCII 226 between the seconds and the AM/PM part of the time suddenly. Edge is not having any issues nor are older versions of Chrome. 110+ has the issue and 109 or earlier does not.

For example, if the last couple of characters returned are:

00 AM

The ASCII translation of that is:

48 48 226 128 175

That 226 used to be a 32 (space).

Anyone else seeing this behavior as well?

• javascript
• google-chrome

Share Improve this question Follow asked Feb 10, 2023 at 1:44 user1488803user1488803 17322 silver badges1010 bronze badges 2

• 1 (swear words) This just cost us thousands of dollars in lost productivity. What a profoundly dumb change. I see that the discussion among the Mozilla developers on Bugzilla says things like, "it only affects bad code using naive parsing." No, I'm just sanitizing a time string and passing it to the database, which now says, "(shrug) I don't know what this time string is." They've confused formatting for display with formatting for all other purposes. I've worked around it for now by doing a string replace of this narrow no-break space character with a regular space before I process it further. – CSX321 Commented Feb 15, 2023 at 17:04
• I just noticed that Chrome 110.0.5481.178 has a separator of 32 (space). – Norio Yamamoto Commented Feb 23, 2023 at 6:31

Add a ment  | 

2 Answers 2

Sorted by: Reset to default 7

This is apparently caused by this V8 CL

Here is the summary of this ChangeLog:

[intl] Enhance Date parser to take Unicode SPACE

This is needed to prepare for the landing of ICU72. Allow U+202F in the Date String, which the toLocaleString("en-US") will generate w/ ICU72.

So it's done on purpose, to support the next version of ICU-72. We can thus assume that other browsers will also follow on this.

[Update]

Since this change caused too many web-pat issues, Chrome did patch their Intl implementation against this ICU-72 change and converted these U+202F characters back to U+2000 characters. Apparently, Firefox did the same even before.

I think it's non-breaking space. Non-breaking space
Since it also occurs on Edge110, I think it is derived from Chromium.

const event = new Date('August 19, 1975 23:15:30 GMT+00:00');
const localTime = event.toLocaleTimeString('en-US');
console.log(localTime);
console.log(localTime.indexOf(" "))
console.log(localTime.indexOf("\u{202F}"))
for (let i = 0; i < localTime.length; i++){
  console.log(localTime.charCodeAt(i));
}