Correctly handle ISO reference year for MonthDay

[Manishearth]

https://tc39.es/proposal-temporal/#sec-temporal-calendarmonthdaytoisoreferencedate

2. Return an implementation-defined ISO Date Record, or throw a RangeError exception, as described below.

Currently we return (iso era, 1972) for all calendars.

I'm not quite sure what we ought to do here.

[Manishearth]

I think the standard ought to specify a default Temporal year, much like it specifies a default Temporal epoch

cc @sffc

[Manishearth]

We also have this issue:

https://github.com/boa-dev/temporal/blob/3fa989f0851a7251a8e8a93cb8a092acd9c3b86f/src/builtins/core/calendar.rs#L244-L246

@nekevss the line number for that link has changed; is there something subtle we need to worry about?

I wonder if there is sensible default behavior we can pick here that works for all calendars while we wait for official word from the spec? Curious if @sffc has thoughts.

[nekevss]

Huh, I'm not remembering the exact point on that file.

There wasn't anything particularly subtle being noted. It was mainly the amount of month focused methods involved in non-ISO calendars.

[Manishearth]

Wrote up some options in https://github.com/tc39/proposal-intl-era-monthcode/issues/60#issuecomment-3110120163

[Manishearth]

We now handle most of these according to the spec algorithm except for Chinese/Dangi. I'd like to wait for https://github.com/unicode-org/icu4x/pull/6800 before attempting Chinese/Dangi.

[sffc]

Thought: with the proleptic approximation, we can choose years far in the past and fully cover the 30-day leap months.

[Manishearth]

@sffc My understanding is that most attested Chinese tabular (algorithmic) calendar approximations like pingqi apparently don't cover all leap months. I can't remember my source on this, unfortunately.

I know that Le calendrier chinois: structure et calculs has details on this, I'll check it out later.

It's worth considering: we have an aversion to using out-of-range dates (I certianly do!) but the actual reference year for MonthDay doesn't really matter: it only shows up when formatting in strange scenarios, I think. So we might be fine using something far out of range.

[Manishearth]

Dans la haute antiquité en effet, le mois intercalaire semble parfois avoir été placé systématiquement après le douzième mois, en queue d'année lunaire. De la vingtsixième année des Qin (1"V221) à I"VI04, il aurait continué d'occuper une place de rang fixe, mais pas la même qu'auparavant puisqu'il aurait été rangé juste après le neuvième mois et se serait alors appelé hou jiu yue i&fLftf (neuvième mois postérieur 25).

Le calendrier chinois: structure et calculs p70

it's basically saying that older calendars would fix the leap month e.g. at the end of the year.

[sffc]

The reason we don't have very many leap months in the winter is because the solar terms are shorter in the winter, so it is less likely for there to be a lunation without a major solar term. But, the pínqì approximation makes the solar terms a fixed length, meaning that there should be an equal number of leap months in the winter as in the summer, especially if we use a mean synodic month for the lunar cycle.

[Manishearth]

@sffc Yeah, I think what's going on is that this is highly dependent on the choice of proleptic approximation; some evenly distribute leap months, others only put them at certain points of the year.

If we wish to use a proleptic approximation that was in historical use, we may be stuck to ones that are less flexible. But we don't have to, if pinqi gets us that behavior.