The ISO-based data model agreed in #290 is almost perfect, but there are a couple cases where it doesn't completely work.

1. Multiple lunar months can occur in the same Gregorian month.
   • For example, in Gregorian May 2022, Hebrew Isan 5782 starts and ends, and we also have both Nissan 30 and Sivan 1.
2. Multiple lunar days can occur in the same Gregorian solar day.
   • For example, the Hawaiian Moon Calendar has 30 days per month, but since the moon cycle is ~29.5 days, every ~2 months, two of the lunar days land on the same solar day.

In both of these cases, what we lose is the ability to round-trip between a calendar-specific date and an ISO date. For example, in YearMonth, the Hebrew calendar could decide to map to the Gregorian month that contains the 1st of the Hebrew month, there is ambiguity in May 2022, since that month contains the 1st of two different Hebrew months.

To address this issue, we need a new slot in the data model. We need it for YearMonth and Date, and maybe MonthDay pending #391.

One can observe that a boolean would be sufficient for both of the cases above. To be more general, we can make the new slot a Number.

We could name this slot [[Shift]]. It defaults to 0. If nonzero, the calendar should add this many minor units. For example, a YearMonth with (IsoYear, IsoMonth, Shift) = (2022, 5, 0) corresponds to Isan 5782, and (2022, 5, 1) corresponds to Sivan 5782. We could alternatively leave the interpretation of the field fully up to the calendar system.

Bikeshed for the name of this new slot:

• [[Shift]]
• [[CalendarShift]]
• [[CalendarData]] (implies a free-form field rather than one with a specific interpretation)
• [[CalendarInfo]]