Manish Goregaokar

> Would it change your opinion if we shipped type aliases for the common cases, which is something I kind-of wanted to do anyway? For example, Not really, no, since...

Oh, if we did end up going the `YMD` route I think we very very much should do the aliases you mentioned, though.

Worth noting, macro-ing the constructor doesn't necessarily make the type easier to read. Hmm, if we're discussing things like macro-ified `{Year, Month, Day}`, then it's worth mentioning that without any...

I think Zibi's arguments make me more amenable to YMD as well, especially with his comments about what the reader of the code will care about. @zbraniecki do you have...

Here's the full list of components I can find: - Day: Era, Year, Month, Day - Time: Hour, Hour12, Hour24, Minute, Second, DayPeriod - Zone: These are weird. We don't...

> I'm open to exploring the tuple path. I think it's even more trait madness to make it work, but it has a nice outcome. I'll respond to the rest...

@sffc your potential mapping should probably include the aspirational field types to be complete, yes? - WeekOfYear: `Wy` - WeekOfMonth: `Wm` - YearOfWeek: `Yw`???? - YearPeriod: `Py`? - DayPeriod: `Pd`?...

> Maybe not a huge deal since "MDY" and "DMY" wouldn't be valid identifiers. Yeah, in general I think the needs of this API is that it should be readable,...

I think hardcoding it is probably better, and we should test it. We can test it against CLDR data as well.

Sounds good, though some additional changes to how attribute parsing works may need to happen to support the reason field.