Bug 209783 – [ECMA-402] Fix Intl.DateTimeFormat patterns and fields in WebKit

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Shane Carr]

Two normative PRs in ECMA-402 changed some behavior relating to non-Gregorian calendars in Intl.DateTimeFormat:

- https://github.com/tc39/ecma402/pull/349
- https://github.com/tc39/ecma402/pull/351

V8 and SM now implement the new behavior described in those PRs.  WebKit users will get lower-quality i18n behavior relative to other browsers until these PRs are also fixed in WebKit.

[Radar WebKit Bug Importer]

<rdar://problem/61079799>

[Ross Kirsling]

Created attachment 396254 [details]
Patch

[Ross Kirsling]

Comment on attachment 396254 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=396254&action=review

> JSTests/test262/config.yaml:159
> +    # These tests require macOS system ICU to actually update its CLDR data >:(
> +    # https://bugs.webkit.org/show_bug.cgi?id=209783
> +    - test/intl402/DateTimeFormat/prototype/format/related-year-zh.js
> +    - test/intl402/DateTimeFormat/prototype/formatToParts/related-year-zh.js

This is super frustrating, but evidently the CLDR data in current Catalina is much older than what should be included with ICU 64 (namely, CLDR 35).

You can see its zh locale data here:
https://opensource.apple.com/source/ICU/ICU-64243.0.1/icuSources/data/locales/zh.txt.auto.html

It lacks this change which should go back to at least ICU 60 (meaning all WK platforms are meant to have it):
https://github.com/unicode-org/icu/commit/77775f1b2d1e3999c0e64ee6db672eeefad9aa3e

[Ross Kirsling]

Created attachment 396255 [details]
Patch

[Keith Miller]

Comment on attachment 396255 [details]
Patch

r=me

[EWS]

Committed r260145: <https://trac.webkit.org/changeset/260145>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 396255 [details].