Manish Goregaokar

@sffc and I discussed this a bunch, in the context of fixing https://github.com/unicode-org/icu4x/issues/3766 and https://github.com/unicode-org/icu4x/issues/3761, which involves adding more data to datetime _anyway_, which we don't want to V2 for...

cc @zbraniecki @robertbastian

Also our plan for https://github.com/unicode-org/icu4x/issues/3766 and https://github.com/unicode-org/icu4x/issues/3761 for 1.3 is to just let it slip and document the chinese calendar as being a preview calendar when it comes to formatting....

Discussed a bit - @Manishearth - Leap month display is a bit of a mess; we can't use a string table because of numbering systems. A similar thing for cyclic...

Discussion between @sffc and I on whether we should use aux keys or regular keys for lengths. We didn't dive too deep into the hour cycle part since that is...

Listing out aux keys for each thing: (a/n/s/w = abbr/narrow/short/wide, f/s = format/standalone) - Months: a/n/w × f/s - Special key "numeric". We probably want a separate key for this,...

Makes sense. My instinct is to let format be the "default" because in some cases there is no data for standalone and we can save space by hardcoding that assumption...

The current design for DTF integration is that we load one of each type of field needed (one month symbol, etc). If a pattern needs multiple fields, we can later...

> Numeric becomes an optional auxiliary key (like another type of length) for calendars that have special formatting for numeric months (with leap year patterns), days, etc. We attempt to...

After convincing myself that we do have plenty of space I'm comfortable going with @sffc's option, since it doesn't increase data size at all except in JSON mode. If people...