Shane F. Carr

There is some interesting code to handle some of this resolution logic in components/datetime/src/pattern/hour_cycle.rs I also observe that we already have the preferred hour cycle (h11h12 or h23h24) in ICU4X...

We still need to figure out a way to support ECMA-402's `hour12` in ICU4X. It has always been really clunky how there are two ways of specifying _almost_ the same...

CLDR ticket: https://unicode-org.atlassian.net/browse/CLDR-18894

A potential proposal: | Value of `-u-hc` | Name | Description | Comments | |---|---|---|---| | h11 | H11 | 12-hour cycle, 0-11 | | h12 | H12 | 12-hour...

I'm pulling this up to 2.2 since it is being added to CLDR in the next release.

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

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...

> 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....

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: ```javascript new Intl.DateTimeFormat("ja-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...