Robert Bastian

I did some googling: * MDN does point out that `h24` is not used anywhere: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getHourCycles#supported_hour_cycle_types * There is also a `hour12` flag, which sounds like it is already not...

And, as the one stackoverflow user noted, 00:30 on Friday should be 24:30 *on Thursday*, but `h24` would return 24:30 on Friday. So it does not even match the Japanese...

The only case where this can happen is if a zone has a different DST offset than the golden zone: https://unicode.org/reports/tr35/tr35-dates.html#goals:~:text=Except%20for%20daylight%20savings%2C%20at%20any%20given%20time%2C%20all%20zones%20in%20a%20metazone%20have%20the%20same%20offset%20at%20that%20time. We can add a `non_standard_dst` flag to `MetazonePeriodsV1`, and...

Ah actually `America/Phoenix` will never have `ZoneVariant::daylight()`. We would need to add the flag to `ZoneOffsetPeriodsV1`, so that we can determine whether the zone variant is ~standard~ regular.

> Oh, hmm, yeah that might work, although it would mean that you get "Mountain Time (Denver)", so basically one bad apple spoils the format for all time zones in...

> Maybe we just mark America/Phoenix as "strange" (within a certain period of time) and print "Mountain Time (Phoenix)" all year round? It would have to be all year round,...

> > CLDR wants us to use the TZDB for this. > > CLDR only says: "when the generic non-location format is not specific enough" which very non-specific. \* I...

ICU requires a full TZDB, so they can do the clever thing. We don't want to ship a full TZDB.

Only if we want to do the fancy thing of only giving Phoenix special treatment while Denver is observing DST. If we special-case it year-round that can be derived from...

We can mark `America/Phoenix` as weird in the metazone lookup. We have spare bits in the ASCII encoding. For example we could encode `Ammt` instead of `ammt` for "belongs to...