Decide behavior for Hebrew common/leap resolution

[sffc]

There are a few operations that need behavior decisions:

1. Adar (M06) in a Common Year + 1 Year
2. Adar I (M05L) in a Leap Year + 1 Year
3. Adar II (M06) in a Leap Year + 1 Year
4. Constraining M05L in a Common Year during construction

I've asked colleagues about these questions, and the consensus seems to be that there isn't a universally accepted answer. Here is an excellent source in English:

https://schechter.edu/when-a-person-passed-away-in-adar-when-is-the-yahrzeit-observed-in-a-leap-year-responsa-in-a-moment-volume-5-issue-no-4-february-2011/

Here's what I currently have in #69:

1. Adar (M06) in a Common Year + 1 Year => M05L
2. Adar I (M05L) in a Leap Year + 1 Year => M06
3. Adar II (M06) in a Leap Year + 1 Year => M06
4. Constraining M05L in a Common Year during construction => M06

Note that the choice impacts mixed year/month arithmetic. If you do +1yr1mo, it will add 1yr first, according to the rules above, and then add 1mo, which simply rolls to the next month. I do not want to special-case that part of the algorithm for Hebrew.

[sffc]

One downside of the algorithm I currently have in #69 is that it needs to know whether the start year is leap and whether the end year is leap, which is extra logic that could be avoided by simply making M06 stay as M06 in both directions.

[sffc]

CC @Manishearth

[Manishearth]

Personally I feel that having M06 stay M06 makes more sense.

There's also a question of whether this should be calendar dependent (requiring per calendar research). I think it's perfectly valid for Temporal to say "adding a year to a non leap month will ALWAYS produce the same month" as a property we uphold. This is very much the type of thing that people will disagree on between groups, and even within the same group people may disagree on based on the use case (e.g. holidays vs birthdays), so having something well defined is more important than matching the cultural expectation, which tends to be less well defined.

[sffc]

There's also a question of whether this should be calendar dependent (requiring per calendar research). I think it's perfectly valid for Temporal to say "adding a year to a non leap month will ALWAYS produce the same month" as a property we uphold.

I agree in principle, of course, but two issues:

1. How do you define "same month"? M05L is the "same month" as non-leap M06 by a lot of sources.
2. There needs to be some Hebrew-specific logic because it is objectively wrong to map M05L to M05 in a common year. Otherwise, I would love for the algorithm to be "remove the L when going from leap to common year".

[sffc]

I surveyed other Googlers familiar with the calendar, and asked them a series of questions. Here's what I found:

• Person 1:
  • "If you add a year + a month to Adar I, and the following year is a leap year, that would put you into Adar II, not Nissan."
  • "Common year -> Leap year: Adar II + (year+month) = Adar II. Common-year Adar II + a year = Adar I, which gets inserted before Adar II in a leap year. Then the +month takes you into Adar II."
• Person 2:
  • "in rare (relatively - 7 out of 19 years) cases, then Adar + 1 year + 1 month will be Adar II."
• Person 3:
  • "My personal intuition is to use Purim's example, and consider only Adar II as the real Adar, thus mapping (Adar or Adar I or Adar II) + year to Adar II or Adar. On the other hand, if there is a thousand year debate about it, whom am I to decide?"

So it's 2 votes for "common Adar + 1yr = Adar I" and 1 vote for "common Adar + 1yr = Adar II".

Maybe we can also include RFC 7529 as a vote for Adar II, given that they "insert" Adar I before Adar II.

https://datatracker.ietf.org/doc/html/rfc7529

[Manishearth]

How do you define "same month"? M05L is the "same month" as non-leap M06 by a lot of sources.

Same month code, I mean.

There needs to be some Hebrew-specific logic because it is objectively wrong to map M05L to M05 in a common year. Otherwise, I would love for the algorithm to be "remove the L when going from leap to common year".

Yes, that's fine, I'm only talking about "adding to a non leap month". The other case requires calendar specific data. This case does not, and I think there is value in avoiding it here.

Generally in lunisolar calendars it is not a big deal to assume "regular month corresponding to a leap month" as a consistent concept built in to the calendar. I think being calendar dependent here is fine.

However "month corresponding to a regular month in a leap year" is not as easily consistent and has more opportunities for ambiguity. Avoiding calendar ambiguity here is useful and good, IMO.

[sffc]

RFC 7529 has a flag for this:

   The "SKIP" element allows
   the calendar user agent to specify new options for handling invalid
   dates.

      "SKIP=OMIT": this is the default option and corresponds to the
      existing iCalendar behavior of simply ignoring the invalid date.

      "SKIP=BACKWARD": when this option is set, a date with an invalid
      month is changed to the previous (valid) month.  A date with an
      invalid day-of-month is changed to the previous (valid)
      day-of-month.

      "SKIP=FORWARD": when this option is set, a date with an invalid
      month is changed to the next (valid) month.  A date with an
      invalid day-of-month is changed to the next (valid) day-of-month.

   Note that for both "BACKWARD" and "FORWARD", if the month is changed
   and results in an invalid day-of-month, then the skip behavior will
   be reapplied as per the day-of-month rules, according to the
   processing order defined below.

This is for recurrence rules (meetings that occur annually, for example).

[sffc]

I implemented "M06 always stays M06, and M05L becomes M06 in a common year" in #73. I don't think there's anything else actionable here.