Test Web Compatibility requirements for implementation-defined locale-specific ECMAScript APIs

[mathiasbynens]

https://bugs.chromium.org/p/chromium/issues/detail?id=1414292 is an example of a high-impact Web Compatibility issue resulting in an emergency Chrome respin earlier this year. It was caused by new Date('…').toLocaleString('en-US') changing from '2/15/2023, 12:00:00 AM' (using U+0020 as the space character) to '2/15/2023, 12:00:00\u202FAM' in ICU 72, following a Unicode CLDR change. (Other locale-sensitive APIs such as Intl.DateTimeFormat.prototype.format were similarly affected.)

Unfortunately, adding Test262 tests for this now-known Web Compat issue is not an option since Date.prototype.toLocaleString and other locale-sensitive ECMAScript APIs tend to be specified as implementation-defined.

However, given the demonstrated Web Compat impact, I’d argue that this specific aspect of the output is now a de facto requirement, and I’m proposing to add Web Platform Tests coverage for it.

[wpt-pr-bot]

There are no reviewers for this pull request. Please reach out on the chat room to get help with this. Thank you!

[mathiasbynens]

Note that I intentionally kept both the file name and the title generic enough, to allow us to add more historical examples of known Web Compat breakages to this file in the future.

[annevk]

Not regressing this seems good, so approving based on that.

What's the standardization follow-up going to look like here? Did CLDR revert its changes, do we need to maintain monkey patches on top of CLDR somewhere? At the very least we need some kind of tracking issue somewhere I think.

[littledan]

Thanks for writing tests here! Yeah, quite unfortunate that the world depends on CLDR not changing in certain ways, but this is sort of the standard drill for Unicode folks, who are well aware of such compat issues.

Note that you’re allowed to put these in test262 as well: just use the metadata locale: ['en'] to indicate that you are relying on specific locale data from English which is theoretically unstable. Cc @ptomato @sffc

[annevk]

Also, fine as a follow-up, could you add a README.md to this directory describing its general purpose?

[ptomato]

Note that you’re allowed to put these in test262 as well: just use the metadata locale: ['en'] to indicate that you are relying on specific locale data from English which is theoretically unstable.

We'd like to move test262 towards a more robust locale-independent way of testing things like this (see tc39/test262#3786), so WPT seems like the right place for this.

[mathiasbynens]

What's the standardization follow-up going to look like here? Did CLDR revert its changes, do we need to maintain monkey patches on top of CLDR somewhere? At the very least we need some kind of tracking issue somewhere I think.

CLDR didn’t revert the change, but instead added alt="ascii" forms with the good ol’ regular space for en-* locales. In practice, browsers and other JS engines should use this form for compatibility reasons. unicode-org/cldr#2897

Also, fine as a follow-up, could you add a README.md to this directory describing its general purpose?

Done

[annevk]

I see, that does seem like something that ought to be defined somewhere.

This is good to merge though. Thanks for adding the README!