iso8601 as DateTimeFormat calendar

[ptomato]

See discussion starting at tc39/test262#4676 (comment)

Should new Intl.DateTimeFormat('en-u-ca-iso8601') succeed? If so, what formatting should it produce? If not, is that web compatible?

[eemeli]

Under AvailableCalendars, we currently include this:

The implementation-defined abstract operation AvailableCalendars takes no arguments and returns a List of Strings. [...] The List must include "iso8601".

That was added by proposal-intl-enumeration, specifically in response to tc39/proposal-intl-enumeration#45, which was discussed by TG2 in 2022.

I don't see how we could remove support for iso8601 formatting in a web-compatible manner. Actually, I think we really ought to further specify that said calendar ought to always be formatted with 2026-01-31 ISO-8601 style formatting -- which is what it currently does.

[ryzokuken]

This goes along the lines of the timeZone option in Intl.DateTimeFormat that specifically accepts a "UTC" option.

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-12-04.md#iso8601-as-datetimeformat-calendar-1036

CLDR issue: https://unicode-org.atlassian.net/browse/CLDR-10014

[sffc]

We discussed this in the CLDR Design WG. In CLDR 48, the team tried to make this calendar encode "YMD ordering with locale-dependent separators", but it was too difficult to collect robust data for this through the Survey Tool, so the change was backed out. @macchiati suggests deprecating the calendar for formatting purposes until CLDR figures out what to do with it.

---

As far as ECMA-402 is concerned, what should we do?

1. Remove the spec text that requires iso8601 to be a formatting calendar. Engines fall back to locale default calendar.
2. Remove the spec text and ask engines to fall back to Gregorian.
3. Change the spec text to require falling back to Gregorian.
4. Change the spec text to fall back to Gregorian but use negative years instead of eras.
5. Something else?

[eemeli]

Given that we just discussed this, and concluded with:

“iso8601 calendar but designed for human consumption” is something that people on this call seem to like.

I don't see why we would start considering adding spec text that considers falling back to Gregorian.

I'm also quite concerned that this change is not even mentioned in the CLDR 48 release notes, even though it's going to impact users on the web. Since April, we've documented the iso8601 calendar on MDN as:

ISO calendar (variant of the Gregorian calendar with week rules and formatting parameters made region-independent)

I don't have numbers, but I'm relatively certain that we already have users who expect this behaviour:

new Intl.DateTimeFormat('en', { calendar: 'iso8601' }).format() // '2025-12-16'

[sffc]

Given that we just discussed this, and concluded with:

“iso8601 calendar but designed for human consumption” is something that people on this call seem to like.

I don't see why we would start considering adding spec text that considers falling back to Gregorian.

A concern I raised in the meeting was that we have no data to implement such a format unless CLDR supports it, and it seems that CLDR is unlikely to support it in the near term.

I'm also quite concerned that this change is not even mentioned in the CLDR 48 release notes, even though it's going to impact users on the web.

It's not mentioned because the change was attempted during the survey tool cycle but rolled back before CLDR 48 was released, so CLDR 48 has the same data for this calendar as does CLDR 47:

https://github.com/unicode-org/cldr/blob/acd6d88ae493633240e19a87a721076a8a75c310/common/main/root.xml#L1993

https://github.com/unicode-org/cldr/blob/2ef784e3a4168bc2a43cd1b5b9839b6636f5899c/common/main/root.xml#L1939

Since April, we've documented the iso8601 calendar on MDN as:

ISO calendar (variant of the Gregorian calendar with week rules and formatting parameters made region-independent)

I don't have numbers, but I'm relatively certain that we already have users who expect this behaviour:

new Intl.DateTimeFormat('en', { calendar: 'iso8601' }).format() // '2025-12-16'

Last week my Chrome version was definitely not formatting with this style, but it is today. I'll need to look into what version I might have been using.

If we want to enforce this definition, then either we need to get alignment with CLDR that this is what they intend to keep moving forward, or engines won't be able to use CLDR for this calendar.

[sffc]

Some more info:

The current behavior uses the same patterns for all locales (inherited from root.xml), but it results in garbage in some locales, such as Japanese:

new Intl.DateTimeFormat("ja-u-ca-iso8601", { dateStyle: "long" }).format()
// '2025 12月 16'

This is part of the motivation behind CLDR 48 wanting to "fix" this. However, as part of the "fix", they consider the date and hour separators as fair game to localize, which might be contrary to a goal of ECMA-402 to have an interoperable calendar format.

It would be helpful if TG2 could draft a list of requirements for what we want out of -u-ca-iso8601.

[eemeli]

It's not mentioned because the change was attempted during the survey tool cycle but rolled back before CLDR 48 was released, so CLDR 48 has the same data for this calendar as does CLDR 47:

Ah, thank you for clarifying; I'd misunderstood which change was backed out of CLDR 48.

It would be helpful if TG2 could draft a list of requirements for what we want out of -u-ca-iso8601.

One decent possibility would be to always and only format the output with parts of a human-readable ISO 8601 date/time string, irrespective of the option values. So the output would always be some substring of YYYY-MM-DD hh:mm:ss.sss, possibly followed by a timezone indicator.

Also, just to clarify, is there a reason you specify the -u-ca-iso8601 locale extension, rather than referring to the iso8601 calendar? In a JS context, isn't the locale extension just a way of specifying the calendar, or is there some difference between the two expressions?

[sffc]

One decent possibility would be to always and only format the output with parts of a human-readable ISO 8601 date/time string, irrespective of the option values. So the output would always be some substring of YYYY-MM-DD hh:mm:ss.sss, possibly followed by a timezone indicator.

A few questions to start:

1. Are you able to articulate the motivation for this behavior?
2. Always numeric? Never with spellout month names even if explicitly requested?
3. Always h23 hour cycle, even if h12 is explicitly requested?
4. Always those specific separators? No changing the decimal, date, time, or datetime separator based on locale?
5. Where do you insert the weekday, or do you support weekday?
6. Should the timezone style be fixed, too?

In other words, how far should we go with our invariant? The weakest possible invariant in my opinion is "should be YMD order", which is what CLDR attempted to do and failed due to confusion with translators. The strongest possible invariant is "should match Temporal ISO-8601 output", perhaps with a space instead of a "T" separating date and time, and perhaps with a space-separated instead of bracketed time zone (but still 100% formulaic, not ILD). Or we could land somewhere in the middle.

Also, just to clarify, is there a reason you specify the -u-ca-iso8601 locale extension, rather than referring to the iso8601 calendar? In a JS context, isn't the locale extension just a way of specifying the calendar, or is there some difference between the two expressions?

Not really, I just like to emphasize that this is a locale preference.