Expose non-ISO equivalent of RegulateISODate / NonISOCalendarDateToISO

[Manishearth]

@sffc is working on this on the standards side

We have https://tc39.es/proposal-temporal/#sec-temporal-regulateisodate, which gets called by Temporal in code like this:

// Construct 01-01, Śaka 1927
var nonLeapYearFirstDay = Temporal.PlainDate.from("2005-03-22[u-ca=indian]");
nonLeapYearFirstDay.with({ day: 31 };
console.log(nonLeapYearFirstDay.day) // 30

Temporal throws range errors when constructing out-of-range dates, but .with() is allowed to specify an overflow option.

As such, we need a way to take a set of codes and "constrain" them to that calendar when the overflow option is set.

[Manishearth]

Something that is able to regulate out-of-range Japanese would be good too. I think that comes from CalendarResolveFields, so it may need to be a separate API.

[Manishearth]

I think what we need is an API, which when given ordinal_month, month_code, year, era_year, era (all optional), it can produce appropriately constrained (monthCode, year) values.

This will include:

• Changing the year/eraYear to be in bounds for the given era
• Setting the month code based on the arithmetical month
• Erroring if month and monthCode do not align
• Constraining day to be in bounds, if possible.

[Manishearth]

Actually, the current calendar API allows one to pass in arithmetical year, which Temporal can just choose to do to avoid problems.

The problems arise with ordinal months: we have no API for working with ordinal months provided by the user. At best we can make some guesses for the month code, which isn't great.

[Manishearth]

I wonder how Firefox handles this.

@anba How are you working around the issue that ICU4X expects exact in-bounds eraYear/month/day values and Temporal allows one to (a) "constrain" these values and (b) will adjust eraYear/era to be the right ones for the given date.

Also how you're dealing with Temporal [[Month]] being ordinal month: ICU4X doesn't have any nice APIs for setting them.

Not at a computer right now and I'll go looking at the code eventually, but I figure you'd have requests of us.

[Manishearth]

Ah, found it

https://searchfox.org/mozilla-central/source/js/src/builtin/temporal/Calendar.cpp#1800

So it's doing roughly what I was trying in Temporal before I hit some annoying bugs: manually constructing dates to check in-rangeyness.

Inefficient but workable.

@nekevss I think we can manage with a similar plan. It's not great, but it should work.

[Manishearth]

Yeah, looks like Firefox attempts a couple different ordinal months for calendars with leap years. I guess we can do that.

https://searchfox.org/mozilla-central/source/js/src/builtin/temporal/Calendar.cpp#1297

In the medium term we should definitely have a method that allows constraining fields so that they can be passed to ICU4X.

[anba]

Yes, that's the correct code where ordinal months are mapped to month codes.

Also possibly relevant:

1. Mapping leap month code in non-leap years: https://searchfox.org/mozilla-central/rev/820596a140570007ce22a6c137ce2520676cfffe/js/src/builtin/temporal/Calendar.cpp#1155-1199 (I haven't yet updated the code to match the current definition in https://tc39.es/proposal-intl-era-monthcode/#sup-temporal-nonisodateadd.)
2. Constraining days to not exceed days in month. https://searchfox.org/mozilla-central/rev/820596a140570007ce22a6c137ce2520676cfffe/js/src/builtin/temporal/Calendar.cpp#1221-1240
3. Invalid Japanese era dates: https://searchfox.org/mozilla-central/rev/820596a140570007ce22a6c137ce2520676cfffe/js/src/builtin/temporal/Calendar.cpp#1207-1219

[sffc]

I intend to implement month code to arithmetical month conversion in icu_calendar in a way that conforms with tc39/proposal-intl-era-monthcode#69 except perhaps for the range-checking part.

[Manishearth]

@sffc Do you think a broader constrain API is warranted? ordinal month to month code is by far the most onerous part, but the rest still requires creating multiple dummy dates and checking their information; I think.

[sffc]

Yeah, we need to think about how to plumb the overflow: constrain | reject option through icu4x anyway.

[sffc]

In a tc39/proposal-intl-era-monthcode#69 world, there are multiple places where we could draw the line between ICU4X and Temporal_rs.

Similarly to how I distilled NonISODateAdd and NonISODateUntil down to lower-level calendar operations, I think I can do the same with NonISOCalendarDateToISO and others. This would allow us to push most of the logic into Tepmoral_rs and keep ICU4X super minimal.

Alternatively, we could draw the line slightly higher: anything that involves touching one of the calendar-specific tables ought to live in ICU4X. I think this is the line I had in mind previously. I think the AOs that would be in ICU4X would be:

• Calendar[Date|YearMonth|MonthDay]FromFields except for constraining to the Temporal range
  • Note: This bundles CalendarResolveFields and CalendarDateToISO
• NonISODate[Add|Until] or, perhaps, all of CalendarDate[Add|Until]

Not sure about things like CalendarExtraFields, since that directly goes into plumbing of GetOption calls, which is before ICU4X should be involved.