CODEWITHSUNDEEP
javascriptgoogle-chrome
user1488803
user1488803

Reputation: 173

Javascript toLocaleTimeString() Returning ASCII 226 Instead of Space in Latest Version of Chrome

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?

Upvotes: 6

Views: 828

Answers (2)

Kaiido
Kaiido

Reputation: 137054

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-compat 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.

Upvotes: 7

Norio Yamamoto
Norio Yamamoto

Reputation: 1796

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));
}

Upvotes: 3

Related Questions