Figure out the Rules trait as it relates to Date::from_fields

[sffc]

Since China and Korea have different leap years, in #6910, I added a month_day_to_reference_year function to the new Rules trait that was added by @robertbastian in #6938.

This is intended as a stopgap solution to unblock my Date::try_from_fields PR. We should discuss whether this is the right trait function. Some options:

1. An ECMA-specific month_day_to_reference_year as currently proposed
   • Can be bikeshed: function name? Types of arguments and return value?
2. A similar but less ECMA-specific MonthDay function such as [prev|next]_year_containing(LunarChineseYearData, MonthCode, u8) -> LunarChineseYearData
   • It would return the year containing the given month/day that is less than or greater than the given year.
   • The stock calendars could implement this efficiently for modern dates and maybe special-case the handful of far-away dates, falling back to a linear search.
3. An intermediate solution akin to CalendarResolveFields in ECMA-402: take &mut DateFields and fill in missing fields according to the MissingFieldsStrategy
4. Put the whole try_from_fields on the trait
   • Pro: Aligns with the contract of the Calendar trait
   • Con: Clients need to handle weird behavior like the ECMA-specific options, as well as any options we add in the future
5. Don't have this on the trait at all and use a linear search at runtime following the Temporal algorithm to find the reference year
   • This is what we might have been forced to do if the trait had already been stable
   • Maybe it's not actually that slow: if the year lookup is constant-time, and we need to check only 200 total years in the common case

Related questions:

1. Should we do the same treatment to Hijri? Since all Hijris have the same epoch, I found I didn't need it (see the implementation), but it means that any future Hijri needs to have the same extended year epoch as the stock Hijris.
2. Are we confident enough in this trait for it to be public? I tend to think that we should keep it UnstableSealed for a while.
   • Do we need it to ever be actually stable? It seems like the kind of power-user feature that we can just ask people now and in the future to add the UnstableSealed bound and accept the contract that the trait is subject to change. This is still more convenient for them than having to implement the whole Calendar trait! Should the Rules traits be marked UnstableSealed? #6962

CC @Manishearth

[Manishearth]

One thing I noticed is that the Rules trait primarily deals with year infos, and most things you'll want to calculate is something you can derive from querying 1-2 year infos.

This is perhaps the only time that doesn't work, when you wish to query something for a month-day combo. Perhaps Rules should have a separate .month_day_info() -> MonthDayInfo where MonthDayInfo is a non_exhaustive struct with an ecma_reference_year field, but more might be added over time. If we ever add more monthday speciic behavior, other implementors can opt in to it by exposing more info over MonthDayInfo.

[sffc]

Hmm. It's an interesting idea. MonthDayInfo sounds like something that you might get from a Date or a future MonthDay type. But, the reference year isn't something intrinsically related to a MonthDay. The reference year is merely a way to convert from a month+day to a date. I wouldn't want MonthDay to need to calculate and carry around this little bit of data.

Maybe it's not so bad to say that the trait primarily serves to produce YearInfos, and the YearInfos can come from either an extended year or a month+day.

[Manishearth]

The mental model I'm applying to the name here is "yearinfo is info for a year, monthdayinfo is info for a monthday combo". But it could be called somehting else. The nice thing is that it's extensible, e.g. if we add more ref year algorithms.