More clarity about expected lunisolar calendar behavior for large dates about proposal-temporal HOT 2 OPEN

Temporal gives 3 ways of representing a particular PlainDate:

1. ISO: isoYear, isoMonth, and isoDay with a calendar system (this is the one we use internally in the spec)
2. Codes: era, eraYear, monthCode, and day
3. Scalars: year, month, and day (this is what ICU4X uses internally)

Being able to convert between all three representations without ambiguity is I think the most important invariant. I will call this the equivalence relation.

Temporal also defines the following invariants for the scalar properties:

• year is a signed integer representing the number of years relative to a calendar-specific epoch
• The first month in every year has month equal to 1. The last month of every year has month equal to the monthsInYear property.
• day is a positive integer representing the day of the month.

Following from these definitions and the equivalence relation are the following arithmetic invariants that I coded into ICU4X in unicode-org/icu4x#4904: The following operations must be equivalent: adding or subtracting 1 day to ISO, adding or subtracting 1 day to Codes, and adding or subtracting 1 day to Scalars. One can write a proof that these invariants must be true for the above definitions to hold.

Calendars that seem like they don't obey these invariants should be modified to do so. For example, juligreg skips about 10 days in the 1600s, violating the definition of day. To fix this problem, that particular month should be shortened and the day field should be adjusted to fill the gap. The offset can and should be fixed during formatting.

For reasons the champions have discussed previously, I think it is wise for Temporal to enforce these invariants. It allows careful developers to craft calendar-independent logic: no matter which calendar is in use, there are certain operations that are always sound, operations derived from the above invariants.

from proposal-temporal.

@Manishearth

How important are calendar internal invariants for such dates? These are invariants that are part of the definition of the calendar. For example:
Is it acceptable for an Islamic or Chinese month in the far future to have a number of days other than 29 or 30?
Is it acceptable to have an Islamic year with a number of days other than 354 or 355?

We have finally finalized a proposal named Hijri week calendar (HWC) that is a counterpart of the ISO calendar for Hijri calendars. We have a working Temporal implementation for it.

When doing so we realised that some Hijri calendars like the islamic or the islamic-rgsa don't follow the invariants of the Hijri calendar as you have mentioned. We considered that as a bug that will potentially be fixed in the ICU implementation.

I am mentioning this as to consider a fix for these calendars to make them compatible with the HWC as we are exploring to port the HWC to CLDR.

from proposal-temporal.