# ### Ben Allen, 111th TC39 --- # Intl Era Month Code for Stage 3 --- ## Premise * `Temporal` supports a number of non ISO-8601 calendars * The behaviour of these calendars has always been defined outside of ECMAScript (in practice, CLDR + ICU4C/ICU4X) * `Temporal` adds calendar arithmetic capability * Although we don't want to specify the arithmetic for every calendar, we do want guardrails around implementation—defined behaviour in order to avoid implementation divergence --- ## Goal 1. We shouldn't overspecify behavior for matters on which ECMAScript isn't the correct authority 1. Within that constraint, minimize opportunities for implementation divergence --- ## Additions to ECMA-402 * Descriptions of supported calendars, removing potential ambiguities. * List of valid era codes and aliases, as standardized in CLDR. * Valid ranges for era years for each calendar. * List of epoch years per calendar for `Temporal.PlainDate.prototype.year`. --- ## Additions to ECMA-402 * List of epoch years per calendar for `Temporal.PlainDate.prototype.year` * Specifics on which calendars support eras and week numbers --- ## Additions to ECMA-402 * Constraining behaviour when adding years in lunisolar calendars * Algorithm for determining the difference between two dates * Special handling for CLDR Hijri calendar IDs with implementation-defined algorithm --- ## Editorial changes since last update * Significant spec text cleanup - All Stage 2.7 review feedback addressed * Clarification for behavior of Thai Buddhist calendar * Dates before 1941 proleptic, due to 1941 calendar reform that shifted the starts of years in this calendar from April to January --- ### Normative: Ignore "islamic-rgsa" calendar in DateTimeFormat [#99](https://github.com/tc39/proposal-intl-era-monthcode/pull/99) * The calendar `"islamic-rgsa"` was requested by Oracle in the early 2010s, but never used for any purpose * No real-world usage on the Web platform * No browser meaningfully differentiates it from the other Islamic calendars. * No country recognizes it --- ### Normative: Ignore "islamic-rgsa" calendar in DateTimeFormat [#99](https://github.com/tc39/proposal-intl-era-monthcode/pull/99) * This PR causes the value of `"ca"` (calendar) to be removed from the `_options_` of `CreateDateTimeFmat` when the value of `_options_.[[ca]]` is `"islamic-rgsa"` * This results in attempts to specify `"islamic-rgsa"` to be ignored --- ### Normative: Ignore "islamic-rgsa" calendar in DateTimeFormat [#99](https://github.com/tc39/proposal-intl-era-monthcode/pull/99) * Additionally restricts the list of available calendars * Previous wording: "The List must include" all calendars from the Calendar Types table * New wording: "The list must consist of" all calendars from the Calendar Types table * Precedent for making it a closed list: the list of units is closed to avoid interop problems * Calendars are significantly more complex than units -- each may require an algorithm, month codes, etc. --- ## Normative: Provide hardcoded table of reference years for Chinese and Dangi leap months[#108](https://github.com/tc39/proposal-intl-era-monthcode/pull/108) * `Temporal.PlainMonthDays` internally store dates as extant dates in the ISO 8601 calendar, consisting of the month, the day, and a year in which the month and day actually occurred * For some lunisolar calendars (chinese/dangi/islamic), there is no year that contains all months and all month lengths * Some leap months are *very* rare. For example, in the Chinese calendar, leap months in the winter almost never happen * In these cases, finding a reference year can involve going into the deep past * Several haven't occured before the calendars in question were designed * Some haven't occured at any point in recorded history, and will not occur at any point in the foreseeable future --- ## Normative: Provide hardcoded table of reference years for Chinese and Dangi leap months[#108](https://github.com/tc39/proposal-intl-era-monthcode/pull/108) * This PR provides a table of reference years for these calendars for all leap months/days that actually exist * Table values are the same as values resulting from following the algorithm already present in the spec text * Additionally, this proposal constrains attempts to refer to nonexistent leap months and leap days by * Rejecting them when the `_overflow_` option is set to `"reject"` * Clamping them to the extant corresponding non-leap month/day when `_overflow_` is `"constrain"` * For example, M01L is constrained to M01 * M12L is constrained to M12 --- ## Bug fix: remove spurious normative change introduced in conversion from prose algorithm descriptions * A PR from mid-2025 replaced the prose algorithm for `NonISODateUntil` with algorithm steps * There was a subtle observable change in the behavior of the Hebrew calendar * See [this table](https://github.com/tc39/proposal-intl-era-monthcode/issues/96#issuecomment-3731113671) * The "Proposed result" column represents the result after this PR lands * The results in this column reflect the behavior of the previous, prose algorithm version of the spec --- ## Stage 3? --- ## Thank you! ---