Intl.DateTimeFormat format matching

[longlho]

When I do

new Intl.DateTimeFormat('en', {
      weekday: 'long',
      era: 'long',
      year: 'numeric',
      month: 'numeric',
      day: 'numeric',
      hour: 'numeric',
      minute: 'numeric',
      second: 'numeric',
      hour12: true,
      formatMatcher: 'basic',
    }).format(1592282900463)

it consistently returns Tuesday, 6 16, 2020 Anno Domini, 12:48:20 AM in Chrome, FF & Safari. However based on https://github.com/unicode-cldr/cldr-dates-full/blob/master/main/en/ca-gregorian.json and LDML Skeleton matching it should be Jun 6 (or such non-numeric month) instead of 6 16. Can someone clarify?

[sffc]

formatMatcher: 'basic' uses a deterministic algorithm, not a CLDR-based algorithm. You want formatMatcher: 'best fit', which is the default.

[longlho]

new Intl.DateTimeFormat('en', {
      weekday: 'long',
      era: 'long',
      year: 'numeric',
      month: 'numeric',
      day: 'numeric',
      hour: 'numeric',
      minute: 'numeric',
      second: 'numeric',
      hour12: true,
    }).format(1592282900463)

same result :(

[sffc]

@pedberg-icu @macchiati can you take a look?

[anba]

Firefox doesn't implement the lookup matcher algorithm at all and I think the other browsers don't implement it, too. Furthermore ICU automatically replaces some date-time fields (*) if they don't match what's in CLDR, but are requested in the input skeleton. This leads to displaying the month as a number when month: 'numeric' is requested. This is specified in https://unicode.org/reports/tr35/tr35-dates.html#Matching_Skeletons; per that algorithm, it's okay to convert an alphabetic element to a numeric element, but not the other way around.

(*) Every field except hour, minute, and second; not sure about fractional seconds right now.

[longlho]

Yup but in the example in the spec it explicitly says:

However, such automatic expansions should never convert a numeric element in the pattern to an alphabetic element. Consider the following dateFormatItem: <dateFormatItem id="yMMM">y年M月</dateFormatItem> If this is the best match for a requested skeleton yMMMM, automatic expansion should not produce a corresponding pattern “y年MMMM月”; rather, since “y年M月” specifies a numeric month M, automatic expansion should not modify the pattern, and should produce “y年M月” as the match for requested skeleton yMMMM.

Nevermind, thanks for the clarification :) Maybe UTS35 could use some clarifications?

[sffc]

Nevermind, thanks for the clarification :) Maybe UTS35 could use some clarifications?

Please file an issue on CLDR JIRA for clarifications to UTS 35. You can cite this issue.

Closing as there does not appear to be anything actionable on the 402 side of things.