Shane F. Carr

> What do you think about the pattern I'm suggesting for IANA -> BCP-47 mapping? Similarly to how I don't think datetime should "manage" the MetazoneCalculator, I don't think it...

My preference, as discussed in #5248, is to replace the input traits with a concrete struct parameterized by `R` (the field set). The struct can have data-driven conversion functions to/from...

> One thing I find unfortunate about the datetime format design is that it _requires_ extracting all of the fieldset information up front, and this applies doubly so if we...

> I think the type parameter has gotten us the significant win of "we don't request week info if we don't need it" but it doesn't extend to not requesting...

https://github.com/unicode-org/icu4x/issues/5533 ```rust struct TimeZone(TimeZoneBcp47Id, Option); struct ResolvedTimeZone(TimeZone, MetazoneId, Option); // Formattable struct OffsetDateTime(DateTime, UtcOffset); // Formattable, IXDTF-parseable (errors when there's no offset) struct ZonedDateTime(DateTime, TimeZone); // IXDTF-parseable (errors when there's...

Does this look right? | Time Zone Type | Input Fields | Resolved Fields | Supported Formatting Styles | |---|---|---|---| | Offset-Only | UtcOffset | UtcOffset | GMT-Offset | |...

@nordzilla @justingrant @leftmostcat for feedback on my above post about time zone data model design.

@justingrant Thanks as usual for your thoughtful reply! A few things: > What are the cases where a caller would supply both? Is this only needed for the formatting case...

> If this remains a formatting-only type, I'd very strongly suggest renaming it to something like ZonedDateTimeFormatter or something like that to make its role super-clear. Otherwise, any developer who's...

> > Hmm, I like calling it `ZonedDateTime`, but `FormattableZonedDateTime` could work. However, if the type doesn't have arithmetic functions, it's not like users could accidentally perform arithmetic with this...