Explainer should mention "iso8601" calendar changes from CLDR46

[anba]

CLDR 46 added new date-time patterns for the ISO-8601 calendar type to the root locale. See https://cldr.unicode.org/downloads/cldr-46#locale-changes. The motivation for this change was to provide a better locale to display ISO-8601 style date-time formats without having to use unrelated locales like "en-DK" or "en-SE". CLDR ticket: https://unicode-org.atlassian.net/browse/CLDR-16446

---

Examples:

js> new Intl.DateTimeFormat("en-u-ca-iso8601").format()
"2025-02-10"
js> new Intl.DateTimeFormat("en-u-ca-iso8601", {year: "numeric", month: "numeric"}).format()                
"2025-02"

When using dateStyle and timeStyle:

js> new Intl.DateTimeFormat("en-u-ca-iso8601", {dateStyle: "full", timeStyle: "full"}).format(Temporal.PlainDateTime.from("2025-02-10T10:15:30"))
"2025 February 10, Monday at 10:15:30"
js> new Intl.DateTimeFormat("en-u-ca-iso8601", {dateStyle: "long", timeStyle: "long"}).format(Temporal.PlainDateTime.from("2025-02-10T10:15:30")) 
"2025 February 10 at 10:15:30"
js> new Intl.DateTimeFormat("en-u-ca-iso8601", {dateStyle: "medium", timeStyle: "medium"}).format(Temporal.PlainDateTime.from("2025-02-10T10:15:30"))
"2025 Feb 10, 10:15:30"
js> new Intl.DateTimeFormat("en-u-ca-iso8601", {dateStyle: "short", timeStyle: "short"}).format(Temporal.PlainDateTime.from("2025-02-10T10:15:30"))   
"2025-02-10, 10:15"

(Note: The "at" separator shouldn't actually be present → https://unicode-org.atlassian.net/browse/CLDR-17968.)

Interestingly the <timeFormat> elements default to a 24-hour clock, which can lead to kind of inconsistent hour-cycle displays. (But that's something which can be easily fixed in JS engines.)

js> new Intl.DateTimeFormat("en-u-ca-iso8601", {timeStyle: "short"}).format(Temporal.PlainTime.from("14:15:30"))                 
"14:15"
js> new Intl.DateTimeFormat("en-u-ca-iso8601", {hour: "numeric", minute: "numeric"}).format(Temporal.PlainTime.from("14:15:30"))
"2:15 PM"

Text components are localised:

js> new Intl.DateTimeFormat("fi-u-ca-iso8601", {year: "numeric", month: "numeric", day: "numeric"}).format()
"2025-02-10"
js> new Intl.DateTimeFormat("fi-u-ca-iso8601", {year: "numeric", month: "long", day: "numeric"}).format()
"2025 helmikuuta 10"

[eemeli]

The motivation for this change was to provide a better locale to display ISO-8601 style date-time formats without having to use unrelated locales like "en-DK" or "en-SE".

Given this motivation, I find it quite surprising for the release notes to include this about -u-ca-iso8601 formatting:

[...] In this first version, the separators are not localized, and will use “-“ within numeric dates, “:” within times, and “ “ or “, “ between major elements. Full localization will await the next submission phase for CLDR.

To me, this sounds like formatting

new Intl.DateTimeFormat("en-u-ca-iso8601", {year: "numeric", month: "numeric"}).format()

could later result in e.g. 2025/02 rather than the current 2025-02.

Is that the intended direction here?

[anba]

Is that the intended direction here?

I don't know the answer to this question (in case it was directed at me).

[eemeli]

Got it. I've asked the question on the Unicode Slack, as the potential locale-dependency of the separators is rather relevant here.