Manish Goregaokar

I do somewhat consider that an _internal_ use case, so it's something where we have some wiggle room on UX. However i am still fine with the proposed policy for...

We're talking about ICU4X here, not Temporal, specifically a part of ICU4X that is not exposed to Temporal.

> I'd rather publish patch releases to fix 1.0 and 1.1 than to impose restrictions on 1.5. (This is also my position, but yeah I'm fine with this for 1.0)

Let's keep discussion on the other issue.

Conclusion: We plan to split this into Month/FormattableMonth and Year/FormattableYear, with Month/Year returning values roughly matching Temporal's needs, and FormattableMonth/FormattableYear returning values matching `icu_datetime`'s needs At that time we can...

I think what needs to be done pre-1.5 is designing these types and potentially adding _private_ APIs for them (or suitably named public APIs). In 2.0 we then move the...

Things needed by Temporal to describe the year/month: - Year: era, eraYear, (extended) year. There is no cyclic year or related_iso. - Month: (ordinal) month, month code We could add...

Ah okay!

I think we already fixed those? But I'd say that's separate. I'd also think changing to Linear is separate.

I'm going to wait for 1.5 for this, it's not worth creating temporary neo types.