Stage 2 Draft / January 21, 2026

Intl era and monthCode Proposal

1 Identification of Locales, Currencies, Time Zones, Measurement Units, Numbering Systems, Collations, and Calendars

1.1 Calendar Types

Editor's Note

This section, Calendar Types, is present in ECMA-402 but is slated to move to ECMA-262 as part of the Temporal proposal. This proposal re-adds the section to ECMA-402, but with additional requirements for Intl-supporting implementations, beyond those specified in ECMA-262.

This specification identifies calendars using a calendar type as defined by Unicode Technical Standard #35 Part 4 Dates, Section 2 Calendar Elements. Their canonical form is a string containing only Unicode Basic Latin lowercase letters (U+0061 LATIN SMALL LETTER A through U+007A LATIN SMALL LETTER Z) with zero or more medial hyphens (U+002D HYPHEN-MINUS).

ECMA-262 describes calendar types, of which "iso8601" is required to be supported. This specification additionally requires ECMAScript implementations to support calendar types corresponding with those of the Unicode Common Locale Data Repository (CLDR).

1.1.1 AvailableCalendars ( )

The implementation-defined abstract operation AvailableCalendars takes no arguments and returns a List of calendar types. The returned List is sorted according to lexicographic code unit order, and contains unique calendar types in canonical form (6.9) identifying the calendars for which the implementation provides the functionality of Intl.DateTimeFormat objects, including their aliases (e.g., either both or neither of "islamicc" and "islamic-civil"). The List must include "iso8601"the "Calendar Type" value of every row of Table 1, except the header row.
Table 1: Calendar types described in CLDR
Calendar Type Description and implementation notes
"buddhist" Thai Buddhist calendar. Month numbers, month codes, and days are identical to ISO 8601, with one era and an epoch year differing from the epoch year in "gregory". All years are treated as having 12 months. For compatibility with other systems, dates prior to ISO year 1941 (2484 BE) are defined but may not correspond to historically accurate values due to the calendar reforms of 1940 and earlier.
"chinese" Traditional Chinese calendar. Lunisolar calendar, based on data published by the Purple Mountain Observatory for dates between 1900 and 2100 (which complies with GB/T 33661-2017, Calculation and Promulgation of the Chinese Calendar), falling back to an implementation-defined approximation outside that range. The arithmetic year is as in "gregory", and there are no eras.
"coptic" Coptic calendar. Similar solar algorithm to "ethioaa" and "ethiopic" but with a different epoch year. There is one era, starting in the epoch year.
"dangi" Traditional Korean calendar. Lunisolar calendar, based on data published by the Korea Astronomy and Space Science Institute (KASI) for dates between 1900 and 2050, falling back to an implementation-defined approximation outside that range. The arithmetic year is as in "gregory", and there are no eras.
"ethioaa" Ethiopic calendar, Amete Alem. Similar solar algorithm to "coptic" and "ethiopic", but with a different epoch year. There is one era, starting in the epoch year.
"ethiopic" Ethiopic calendar, Amete Mihret. Similar solar algorithm to "coptic" and "ethioaa", but with a different epoch year. There are two eras, one starting in the epoch year of "ethioaa" and one starting in this calendar's epoch year.
"ethiopic-amete-alem" Alias for "ethioaa".
"gregory" Gregorian calendar. Solar calendar almost identical to the ISO 8601 calendar, except that it does not define week numbering and it contains two eras, one before the epoch year and one after.
"hebrew" Hebrew calendar. Civil calendar with Tishrei as the first month of the year. Lunisolar calendar with one leap month inserted after month 5. There is one era.
"indian" Indian national (or Śaka) calendar. Solar calendar with one era.
"islamic-civil" Hijri calendar, tabular/rule-based with leap years 2, 5, 7, 10, 13, 16, 18, 21, 24, 26, 29 in the 30-year cycle, and civil epoch (Friday July 16, 622 Julian / 0622-07-19 ISO)
"islamic-tbla" Hijri calendar, tabular/rule-based with leap years 2, 5, 7, 10, 13, 16, 18, 21, 24, 26, 29 in the 30-year cycle, and astronomical epoch (Thursday July 15, 622 Julian / 0622-07-18 ISO)
"islamic-umalqura" Hijri calendar, Umm al-Qura. Lunar calendar using months calculated by King Abdulaziz City for Science and Technology (KACST) for dates from the start of 1300 AH to the end of 1600 AH, falling back to "islamic-civil" outside that range.
"islamicc" Alias for "islamic-civil".
"iso8601" ISO 8601 calendar. Fully specified in ECMA-262.
"japanese" Japanese Imperial calendar, era system hybridised with the era system used in "gregory". Month numbers, month codes, and days are the same as in the ISO 8601 calendar. For dates up to and including 1872-12-31, years and eras identical to "gregory" are used. For later dates, the eras and ranges defined by the Japanese government are used. Note that ISO year 1873 is the 6th year of the Meiji period, starting on ISO date 1868-10-23, during which calendar reforms took place. The arithmetic year is identical to "gregory".
"persian" Persian (or Solar Hijri) calendar. There is one era.
"roc" Republic of China (or Minguo) calendar. Month numbers, month codes, and days are the same as in the ISO 8601 calendar, with two eras, one before the epoch year and one after. The epoch year is different from "gregory".

2 Locale and Parameter Negotiation

2.1 Internal slots of Service Constructors

[...]

Note
For example, an implementation of DateTimeFormat might include the language tag "fa-IR" in its [[AvailableLocales]] internal slot, and must (according to 11.2.3) include the keys "ca", "hc", and "nu" in its [[RelevantExtensionKeys]] internal slot. The default calendar for that locale is usually "persian", but an implementation might also support "gregory", "islamic", and "islamic-civil". The Record in the DateTimeFormat [[LocaleData]] internal slot would therefore include a [[fa-IR]] field whose value is a Record like { [[ca]]: « "persian", "gregory", "islamic", "islamic-civil" », [[hc]]: « … », [[nu]]: « … » }, along with other locale-named fields having the same value shape but different elements in their Lists.

3 DateTimeFormat Objects

3.1 The Intl.DateTimeFormat Constructor

3.1.1 CreateDateTimeFormat ( newTarget, locales, options, required, defaults )

The abstract operation CreateDateTimeFormat takes arguments newTarget (a constructor), locales (an ECMAScript language value), options (an ECMAScript language value), required (date, time, or any), and defaults (date, time, or all) and returns either a normal completion containing a DateTimeFormat object or a throw completion. It performs the following steps when called:

  1. Let dateTimeFormat be ? OrdinaryCreateFromConstructor(newTarget, "%Intl.DateTimeFormat.prototype%", « [[InitializedDateTimeFormat]], [[Locale]], [[Calendar]], [[NumberingSystem]], [[TimeZone]], [[HourCycle]], [[DateStyle]], [[TimeStyle]], [[DateTimeFormat]], [[BoundFormat]] »).
  2. Let hour12 be undefined.
  3. Let modifyResolutionOptions be a new Abstract Closure with parameters (options) that captures hour12 and performs the following steps when called:
    1. Set hour12 to options.[[hour12]].
    2. Remove field [[hour12]] from options.
    3. If hour12 is not undefined, set options.[[hc]] to null.
  4. Let optionsResolution be ? ResolveOptions(%Intl.DateTimeFormat%, %Intl.DateTimeFormat%.[[LocaleData]], locales, options, « coerce-options », modifyResolutionOptions).
  5. Set options to optionsResolution.[[Options]].
  6. Let r be optionsResolution.[[ResolvedLocale]].
  7. Set dateTimeFormat.[[Locale]] to r.[[Locale]].
  8. Let resolvedCalendar be r.[[ca]].
  9. If resolvedCalendar is "islamic" or "islamic-rgsa", then
    1. Let fallbackCalendar be an implementation- and locale-defined calendar type that is one of the values returned from AvailableCalendars.
    2. Set resolvedCalendar to CanonicalizeUValue("ca", fallbackCalendar).
    3. If the ECMAScript implementation has a mechanism for reporting diagnostic warning messages, a warning should be issued.
  10. Set dateTimeFormat.[[Calendar]] to resolvedCalendar.
  11. NOTE: Rest of algorithm unchanged.

3.2 Properties of the Intl.DateTimeFormat Constructor

3.2.1 Internal slots

[...]

The value of the [[LocaleData]] internal slot is implementation-defined within the constraints described in 2.1 and the following additional constraints, for all locale values locale:

  • [[LocaleData]].[[<locale>]].[[ca]] must be a List consisting of calendar types. Specifically, even if supporting only the calendars from Table 1, the list may also include "islamic" and "islamic-rgsa".
  • [[LocaleData]].[[<locale>]].[[nu]] must be a List that does not include the values "native", "traditio", or "finance".
  • [[LocaleData]].[[<locale>]].[[hc]] must be « null, "h11", "h12", "h23", "h24" ».
  • [...]

4 Locale Sensitive Functions of the ECMAScript Language Specification

4.1 Abstract Operations for Calendar Calculations

4.1.1 CalendarSupportsEra ( calendar )

The abstract operation CalendarSupportsEra takes argument calendar (a calendar type) and returns a Boolean. The following algorithm refers (via Table 2) to the era data from Unicode Technical Standard #35 Part 4 Dates, Calendar Data. It performs the following steps when called:

  1. If calendar is listed in the "Calendar" column of Table 2, return true.
  2. If calendar is listed in the "Calendar Type" column of Table 1, return false.
  3. Return an implementation-defined value.

Table 2 lists all currently known eras for the current set of calendars, including their aliases, ranges, and kinds. The canonical source for this table is the data described in Unicode Technical Standard #35 Part 4 Dates, Calendar Data.

The era kind is used by CalendarDateArithmeticYearForEraYear to calculate the arithmetic year ([[Year]]): An Era Kind epoch means that the era is the epoch era, so 1 Era has an arithmetic year of 1. An Era Kind negative means that the era is a "negative" era growing from the epoch, so 1 Era is an arithmetic year of 0, and larger [[EraYear]] values produce smaller, negative arithmetic years. An Era Kind of offset means that the era is "offset" by a given number (in the Offset column), so 1 Era has an arithmetic year of Offset.

Table 2: Eras
Calendar Era Aliases Minimum eraYear Maximum eraYear Era Kind Offset
"buddhist" "be" -∞ +∞ epoch
"coptic" "am" -∞ +∞ epoch
"ethioaa" "aa" -∞ +∞ epoch
"ethiopic" "am" 1 +∞ epoch
"ethiopic" "aa" -∞ 5500 offset -5499
"gregory" "ce" "ad" 1 +∞ epoch
"gregory" "bce" "bc" 1 +∞ negative
"hebrew" "am" -∞ +∞ epoch
"indian" "shaka" -∞ +∞ epoch
"islamic-civil" "ah" 1 +∞ epoch
"islamic-civil" "bh" 1 +∞ negative
"islamic-tbla" "ah" 1 +∞ epoch
"islamic-tbla" "bh" 1 +∞ negative
"islamic-umalqura" "ah" 1 +∞ epoch
"islamic-umalqura" "bh" 1 +∞ negative
"japanese" "reiwa" 1 +∞ offset 2019
"japanese" "heisei" 1 31 offset 1989
"japanese" "showa" 1 64 offset 1926
"japanese" "taisho" 1 15 offset 1912
"japanese" "meiji" 6 45 offset 1868
"japanese" "ce" "ad" 1 1872 epoch
"japanese" "bce" "bc" 1 +∞ negative
"persian" "ap" -∞ +∞ epoch
"roc" "roc" 1 +∞ epoch
"roc" "broc" 1 +∞ negative

4.1.2 CanonicalizeEraInCalendar ( calendar, era )

The abstract operation CanonicalizeEraInCalendar takes arguments calendar (a calendar type that is not "iso8601") and era (a String) and returns a String or undefined. The following algorithm refers to the era data from Unicode Technical Standard #35 Part 4 Dates, Calendar Data. It performs the following steps when called:

  1. For each row of Table 2, except the header row, do
    1. Let cal be the Calendar value of the current row.
    2. If cal is equal to calendar, then
      1. Let canonicalName be the Era value of the current row.
      2. If canonicalName is equal to era, return canonicalName.
      3. Let aliases be a List whose elements are the strings given in the "Aliases" column of the row.
      4. If aliases contains era, return canonicalName.
  2. If calendar is listed in the "Calendar Type" column of Table 1, return undefined.
  3. Return an implementation-defined value.

4.1.3 CalendarHasMidYearEras ( calendar )

The abstract operation CalendarHasMidYearEras takes argument calendar (a calendar type that is not "iso8601") and returns a Boolean. It returns true if the calendar has eras that start in the middle of the year, or false if all eras start on a year boundary. It performs the following steps when called:

  1. If calendar is "japanese", return true.
  2. If calendar is listed in the "Calendar Type" column of Table 1, return false.
  3. Return an implementation-defined value.

4.1.4 IsValidMonthCodeForCalendar ( calendar, monthCode )

The abstract operation IsValidMonthCodeForCalendar takes arguments calendar (a calendar type that is not "iso8601") and monthCode (a month code) and returns a Boolean. It performs the following steps when called:

  1. Let commonMonthCodes be « "M01", "M02", "M03", "M04", "M05", "M06", "M07", "M08", "M09", "M10", "M11", "M12" ».
  2. If commonMonthCodes contains monthCode, return true.
  3. If calendar is listed in the "Calendar" column of Table 3, then
    1. Let r be the row in Table 3 with a value in the Calendar column matching calendar.
    2. Let specialMonthCodes be a List whose elements are the strings given in the "Additional Month Codes" column of r.
    3. If specialMonthCodes contains monthCode, return true.
    4. Return false.
  4. If calendar is listed in the "Calendar Type" column of Table 1, return false.
  5. Return an implementation-defined value.
Table 3: Additional Month Codes in Calendars
Calendar Additional Month Codes Leap to Common Month Transformation
"chinese" "M01L", "M02L", "M03L", "M04L", "M05L", "M06L", "M07L", "M08L", "M09L", "M10L", "M11L", "M12L" skip-backward
"coptic" "M13"
"dangi" "M01L", "M02L", "M03L", "M04L", "M05L", "M06L", "M07L", "M08L", "M09L", "M10L", "M11L", "M12L" skip-backward
"ethioaa" "M13"
"ethiopic" "M13"
"hebrew" "M05L" skip-forward

4.1.5 YearContainsMonthCode ( calendar, arithmeticYear, monthCode )

The abstract operation YearContainsMonthCode takes arguments calendar (a calendar type that is not "iso8601"), arithmeticYear (an integer), and monthCode (a month code) and returns a Boolean. It returns whether the given monthCode exists in arithmeticYear of calendar.

It performs the following steps when called:

  1. Assert: IsValidMonthCodeForCalendar(calendar, monthCode) is true.
  2. If ! ParseMonthCode(monthCode).[[IsLeap]] is false, return true.
  3. Return whether the leap month indicated by monthCode exists in the year arithmeticYear in calendar, using calendar-dependent behaviour.

4.1.6 ConstrainMonthCode ( calendar, arithmeticYear, monthCode, overflow )

The abstract operation ConstrainMonthCode takes arguments calendar (a calendar type that is not "iso8601"), arithmeticYear (an integer), monthCode (a month code), and overflow (constrain or reject) and returns either a normal completion containing a month code or a throw completion. It returns the month code in arithmeticYear of calendar that best matches the given monthCode. If monthCode does not exist in arithmeticYear, it is constrained to the best common month if overflow is constrain, or an error is thrown if overflow is reject.

It performs the following steps when called:

  1. Assert: IsValidMonthCodeForCalendar(calendar, monthCode) is true.
  2. If YearContainsMonthCode(calendar, arithmeticYear, monthCode) is true, return monthCode.
  3. If overflow is reject, throw a RangeError exception.
  4. If calendar is not listed in the "Calendar Type" column of Table 1, return an implementation-defined value.
  5. Assert: calendar is listed in the "Calendar" column of Table 3.
  6. Let r be the row in Table 3 with a value in the Calendar column matching calendar.
  7. Let shiftType be the value given in the "Leap to Common Month Tranformation" column of r.
  8. If shiftType is skip-backward, then
    1. Return CreateMonthCode(! ParseMonthCode(monthCode).[[MonthNumber]], false).
  9. Else,
    1. Assert: monthCode is "M05L".
    2. Return "M06".

4.1.7 MonthCodeToOrdinal ( calendar, arithmeticYear, monthCode )

The abstract operation MonthCodeToOrdinal takes arguments calendar (a calendar type that is not "iso8601"), arithmeticYear (an integer), and monthCode (a month code) and returns an integer. It returns the ordinal month number for monthCode in arithmeticYear of calendar. The given monthCode must exist in the given year.

It performs the following steps when called:

  1. Assert: YearContainsMonthCode(calendar, arithmeticYear, monthCode) is true.
  2. Let monthsBefore be 0.
  3. Let number be 1.
  4. Let isLeap be false.
  5. If calendar is not listed in the "Calendar Type" column of Table 1, return an implementation-defined value.
  6. Let r be the row in Table 3 with a value in the Calendar column matching calendar.
  7. If the "Leap to Common Month Tranformation" column of r is empty, then
    1. Return ! ParseMonthCode(monthCode).[[MonthNumber]].
  8. Assert: The "Additional Month Codes" column of r does not contain "M00L" or "M13".
  9. Assert: This algorithm will return before the following loop terminates by failing its condition.
  10. Repeat, while number ≤ 12,
    1. Let currentMonthCode be CreateMonthCode(number, isLeap).
    2. If IsValidMonthCodeForCalendar(calendar, currentMonthCode) is true and YearContainsMonthCode(calendar, arithmeticYear, currentMonthCode) is true, then
      1. Set monthsBefore to monthsBefore + 1.
    3. If currentMonthCode is monthCode, then
      1. Return monthsBefore.
    4. If isLeap is false, then
      1. Set isLeap to true.
    5. Else,
      1. Set isLeap to false.
      2. Set number to number + 1.

4.1.8 CalendarDaysInMonth ( calendar, arithmeticYear, ordinalMonth )

The abstract operation CalendarDaysInMonth takes arguments calendar (a calendar type that is not "iso8601"), arithmeticYear (an integer), and ordinalMonth (a positive integer) and returns an integer. The returned value represents the number of days in the calendar-specific arithmeticYear and ordinalMonth.

4.1.9 CalendarDateEra ( calendar, date )

The abstract operation CalendarDateEra takes arguments calendar (a calendar type that is not "iso8601") and date (an ISO Date Record) and returns a String or undefined. It performs implementation-defined processing to find the era for the date corresponding to date in the context of the calendar represented by calendar and returns a lowercase String value representing that era, or undefined for calendars that do not have eras. It performs the following steps when called:

  1. If CalendarSupportsEra(calendar) is false, return undefined.
  2. Let era be the String to indicate the era corresponding to date in the context of the calendar represented by calendar according to implementation-defined processing.
  3. Return CanonicalizeEraInCalendar(calendar, era).

4.1.10 CalendarDateEraYear ( calendar, date )

The abstract operation CalendarDateEraYear takes arguments calendar (a calendar type that is not "iso8601") and date (an ISO Date Record) and returns an integer or undefined. It performs implementation-defined processing to find the era for the date corresponding to date in the context of the calendar represented by calendar and returns an integer representing the ordinal position of the year of date in that era, or undefined for calendars that do not have eras. It performs the following steps when called:

  1. If CalendarSupportsEra(calendar) is false, return undefined.
  2. Let eraYear be the integer to indicate the era year corresponding to date in the context of the calendar represented by calendar according to implementation-defined processing.
  3. Assert: eraYear is an integer.
  4. Return eraYear.

4.1.11 CalendarDateArithmeticYear ( calendar, date )

The abstract operation CalendarDateArithmeticYear takes arguments calendar (a calendar type that is not "iso8601") and date (an ISO Date Record) and returns an integer. It performs implementation-defined processing to find the arithmetic year for the date corresponding to date in the context of the calendar represented by calendar. It performs the following steps when called:

  1. If calendar is not listed in the "Calendar Type" column of Table 1, return an implementation-defined value.
  2. Let r be the row in Table 4 with a value in the Calendar column matching calendar.
  3. Let epochYear be the value given in the "Epoch ISO Year" column of r.
  4. Let epochDate be the first day of the calendar year starting in ISO year epochYear in the calendar represented by calendar, according to implementation-defined processing.
  5. Let newYear be the first day of the calendar year of date in the calendar represented by calendar, according to implementation-defined processing.
  6. Let arithmeticYear be the signed number of whole years between epochDate and newYear in the calendar represented by calendar, according to implementation-defined processing.
  7. Return arithmeticYear.
Table 4: Epoch years
Calendar Epoch ISO Year
"buddhist" -543
"chinese" 0
"coptic" 283
"dangi" 0
"ethioaa" -5493
"ethiopic" 7
"gregory" 0
"hebrew" -3761
"indian" 78
"islamic-civil" 621
"islamic-tbla" 621
"islamic-umalqura" 621
"japanese" 0
"persian" 621
"roc" 1911

4.1.12 CalendarDateArithmeticYearForEraYear ( calendar, era, eraYear )

The abstract operation CalendarDateArithmeticYearForEraYear takes arguments calendar (a calendar type that has eras), era (a String), and eraYear (an integer) and returns an integer. It produces the arithmetic year for a given set of era, eraYear in calendar, a calendar that includes an era named era. It performs the following steps when called:

  1. Let era be CanonicalizeEraInCalendar(calendar, era).
  2. Assert: era is not undefined.
  3. If calendar is not listed in the "Calendar Type" column of Table 1, return an implementation-defined value.
  4. Let r be the row in Table 2 with a value in the Calendar column matching calendar and a value in the Era column matching era.
  5. Let eraKind be the value given in the "Era Kind" column of r.
  6. Let offset be the value given in the "Offset" column of r.
  7. If eraKind is epoch, return eraYear.
  8. If eraKind is negative, return 1 - eraYear.
  9. Assert: eraKind is offset.
  10. Assert: offset is not undefined.
  11. Return offset + eraYear - 1.

4.1.13 CalendarIntegersToISO ( calendar, arithmeticYear, ordinalMonth, day )

The abstract operation CalendarIntegersToISO takes arguments calendar (a calendar type that is not "iso8601"), arithmeticYear (an integer), ordinalMonth (a positive integer), and day (a positive integer) and returns either a normal completion containing an ISO Date Record or a throw completion. It returns an ISO Date Record that corresponds with the given calendar-specific arithmeticYear, ordinalMonth, and day.

It performs the following steps when called:

  1. If arithmeticYear, ordinalMonth, and day do not form a valid date in calendar, throw a RangeError exception.
  2. Let isoDate be an ISO Date Record such that CalendarISOToDate(calendar, isoDate) returns a Calendar Date Record whose [[Year]], [[Month]], and [[Day]] field values respectively equal arithmeticYear, ordinalMonth, and day.
  3. NOTE: No known calendars have repeated dates that would cause isoDate to be ambiguous between two ISO Date Records.
  4. Return isoDate.

4.1.14 Calendar Date Records

A Calendar Date Record is a Record value used to represent a valid calendar date in a non-ISO 8601 calendar. Calendar Date Records are produced by the abstract operation CalendarISOToDate.

Calendar Date Records have the fields listed in Table 5.

This definition supersedes the one in Temporal, 12.2.1.

Table 5: Calendar Date Record Fields
Field Name Value Meaning
[[Era]] a String or undefined A lowercase String value representing the date's era, or undefined for calendars that do not have eras.
The value of this field for a calendar type calendar should be the result of calling CalendarDateEra(calendar, date), where date is the [[ISODate]] field of a Temporal.PlainDateTime, Temporal.PlainDate, or Temporal.PlainYearMonth value corresponding to the date.
[[EraYear]] an integer or undefined The ordinal position of the date's year within its era, or undefined for calendars that do not have eras.
The value of this field for a calendar type calendar should be the result of calling CalendarDateEraYear(calendar, date), where date is the [[ISODate]] field of a Temporal.PlainDateTime, Temporal.PlainDate, or Temporal.PlainYearMonth value corresponding to the date. Note 1
Era years are 1-indexed for many calendars, but not all (e.g., the eras of the Burmese calendar, not currently available in CLDR, each start with a year 0). Years can also advance opposite the flow of time (as for BCE years in the Gregorian calendar).
[[Year]] an integer The date's arithmetic year, which is the year relative to the first day of a calendar-specific epoch year, given in Table 4.
The value of this field for a calendar type calendar should be the result of calling CalendarDateArithmeticYear(calendar, date), where date is the [[ISODate]] field of a Temporal.PlainDateTime, Temporal.PlainDate, or Temporal.PlainYearMonth value corresponding to the date. Note 2
The arithmetic year is relative to the first day of the calendar's epoch year, so if the epoch era starts in the middle of the year, the year will be the same value before and after the start date of the era.
[[Month]] a positive integer The 1-based ordinal position of the date's month within its year. Note 3
When the number of months in a year of the calendar is variable, a different value can be returned for dates that are part of the same month in different years. For example, in the Hebrew calendar, 1 Nisan 5781 is associated with value 7 while 1 Nisan 5782 is associated with value 8 because 5782 is a leap year and Nisan follows the insertion of Adar I.
[[MonthCode]] a String The month code of the date's month. The month code for a month that is not a leap month and whose 1-based ordinal position in a common year of the calendar (i.e., a year that is not a leap year) is n should be the string-concatenation of "M" and ToZeroPaddedDecimalString(n, 2), and the month code for a month that is a leap month inserted after a month whose 1-based ordinal position in a common year of the calendar is p should be the string-concatenation of "M", ToZeroPaddedDecimalString(p, 2), and "L". Note 4
For example, in the Hebrew calendar, the month code of Adar (and Adar II, in leap years) is "M06" and the month code of Adar I (the leap month inserted before Adar II) is "M05L". Theoretically, in a calendar with a leap month at the start of some years, the month code of that month would be "M00L".
[[Day]] a positive integer The 1-based ordinal position of the date's day within its month.
[[DayOfWeek]] a positive integer The day of the week corresponding to the date. The value should be 1-based, where 1 is the day corresponding to Monday in the given calendar.
[[DayOfYear]] a positive integer The 1-based ordinal position of the date's day within its year.
[[WeekOfYear]] a Year-Week Record

The date's calendar week of year, and the corresponding week calendar year.

The Year-Week Record's [[Week]] field should be 1-based.

The Year-Week Record's [[Year]] field is an arithmetic year as in the Calendar Date Record's [[Year]] field, not relative to an era as in [[EraYear]].

Usually the Year-Week Record's [[Year]] field will contain the same value as the Calendar Date Record's [[Year]] field, but may contain the previous or next year if the week number in the Year-Week Record's [[Week]] field overlaps two different years. See also ISOWeekOfYear.

The Year-Week Record contains undefined in [[Week]] and [[Year]] field for calendars that do not have a well-defined week numbering system.

Note 5
Currently, of the calendars supported in this specification, only "iso8601" has a well-defined, locale-independent week numbering system. For all other calendars, the Year-Week Record fields are undefined.
[[DaysInWeek]] a positive integer

The number of days in the primary notion of week used by the calendar. For all calendars currently supported by this specification, this number is 7.

Note 6
Some calendars have alternate cyclic notions that are similar to the 7-day week; many of them have multiple (like the Javanese calendar). This specification does not cover such calendars but can be extended to do so in the future.
[[DaysInMonth]] a positive integer The number of days in the date's month.
[[DaysInYear]] a positive integer The number of days in the date's year.
[[MonthsInYear]] a positive integer The number of months in the date's year.
[[InLeapYear]] a Boolean true if the date falls within a leap year, and false otherwise. Note 7
A "leap year" is a year that contains more days than other years (for solar or lunar calendars) or more months than other years (for lunisolar calendars like Hebrew or Chinese). Some calendars, especially lunisolar ones, have further variation in year length that is not represented in the output of this operation (e.g., the Hebrew calendar includes common years with 353, 354, or 355 days and leap years with 383, 384, or 385 days).

4.1.15 CalendarMonthsInYear ( calendar, arithmeticYear )

The abstract operation CalendarMonthsInYear takes arguments calendar (a calendar type that is not "iso8601") and arithmeticYear (an integer) and returns a positive integer. It interprets arithmeticYear as a year in the given calendar in the same way as CalendarDateArithmeticYear. The returned value represents the number of months in that year.

4.1.16 BalanceNonISODate ( calendar, arithmeticYear, ordinalMonth, day )

The abstract operation BalanceNonISODate takes arguments calendar (a calendar type that is not "iso8601"), arithmeticYear (an integer), ordinalMonth (a positive integer), and day (an integer) and returns a Record with fields [[Year]] (an integer), [[Month]] (a positive integer), and [[Day]] (a positive integer). It interprets the given arithmeticYear, potentially out-of-range ordinalMonth, and potentially out-of-range day as arithmetical values in the given calendar and returns in-range values by overflowing out-of-range ordinalMonth or day values into the next-highest unit. This date may correspond to a date in the ISO calendar that is outside the range given by ISODateTimeWithinLimits.

It performs the following steps when called:

  1. Let resolvedYear be arithmeticYear.
  2. Let resolvedMonth be ordinalMonth.
  3. Let monthsInYear be CalendarMonthsInYear(calendar, resolvedYear).
  4. Repeat, while resolvedMonth ≤ 0,
    1. Set resolvedYear to resolvedYear - 1.
    2. Set monthsInYear to CalendarMonthsInYear(calendar, resolvedYear).
    3. Set resolvedMonth to resolvedMonth + monthsInYear.
  5. Repeat, while resolvedMonth > monthsInYear,
    1. Set resolvedMonth to resolvedMonth - monthsInYear.
    2. Set resolvedYear to resolvedYear + 1.
    3. Set monthsInYear to CalendarMonthsInYear(calendar, resolvedYear).
  6. Let resolvedDay be day.
  7. Let daysInMonth be CalendarDaysInMonth(calendar, resolvedYear, resolvedMonth).
  8. Repeat, while resolvedDay ≤ 0,
    1. Set resolvedMonth to resolvedMonth - 1.
    2. If resolvedMonth is 0, then
      1. Set resolvedYear to resolvedYear - 1.
      2. Set monthsInYear to CalendarMonthsInYear(calendar, resolvedYear).
      3. Set resolvedMonth to monthsInYear.
    3. Set daysInMonth to CalendarDaysInMonth(calendar, resolvedYear, resolvedMonth).
    4. Set resolvedDay to resolvedDay + daysInMonth.
  9. Repeat, while resolvedDay > daysInMonth,
    1. Set resolvedDay to resolvedDay - daysInMonth.
    2. Set resolvedMonth to resolvedMonth + 1.
    3. If resolvedMonth > monthsInYear, then
      1. Set resolvedYear to resolvedYear + 1.
      2. Set monthsInYear to CalendarMonthsInYear(calendar, resolvedYear).
      3. Set resolvedMonth to 1.
    4. Set daysInMonth to CalendarDaysInMonth(calendar, resolvedYear, resolvedMonth).
  10. Return the Record { [[Year]]: resolvedYear, [[Month]]: resolvedMonth, [[Day]]: resolvedDay }.

4.1.17 NonISODateSurpasses ( calendar, sign, fromIsoDate, toIsoDate, years, months, weeks, days )

The abstract operation NonISODateSurpasses takes arguments calendar (a calendar type that is not "iso8601"), sign (-1 or 1), fromIsoDate (an ISO Date Record), toIsoDate (an ISO Date Record), years (an integer), months (an integer), weeks (an integer), and days (an integer) and returns a Boolean. The return value indicates whether the date date1, the result of adding the duration denoted by years, months, weeks, and days to fromIsoDate in the calendar system denoted by calendar, surpasses toIsoDate in the direction denoted by sign. If weeks and days are both zero, then date1 need not exist (for example, it could be February 30).

It performs the following steps when called:

  1. Let parts be CalendarISOToDate(calendar, fromIsoDate).
  2. Let y0 be parts.[[Year]] + years.
  3. Let m0 be MonthCodeToOrdinal(calendar, y0, ! ConstrainMonthCode(calendar, y0, parts.[[MonthCode]], constrain)).
  4. Let endOfMonth be BalanceNonISODate(calendar, y0, m0 + months + 1, 0).
  5. Let baseDay be parts.[[Day]].
  6. If weeks is not 0 or days is not 0, then
    1. If baseDay ≤ endOfMonth.[[Day]], then
      1. Let regulatedDay be baseDay.
    2. Else,
      1. Let regulatedDay be endOfMonth.[[Day]].
    3. Let daysInWeek be 7 (the number of days in a week for all supported calendars).
    4. Let balancedDate be BalanceNonISODate(calendar, endOfMonth.[[Year]], endOfMonth.[[Month]], regulatedDay + daysInWeek * weeks + days).
    5. Let y1 be balancedDate.[[Year]].
    6. Let m1 be balancedDate.[[Month]].
    7. Let d1 be balancedDate.[[Day]].
  7. Else,
    1. Let y1 be endOfMonth.[[Year]].
    2. Let m1 be endOfMonth.[[Month]].
    3. Let d1 be baseDay.
  8. Let calDate2 be CalendarISOToDate(calendar, toIsoDate).
  9. If y1 ≠ calDate2.[[Year]], then
    1. If sign × (y1 - calDate2.[[Year]]) > 0, return true.
  10. Else if m1 ≠ calDate2.[[Month]], then
    1. If sign × (m1 - calDate2.[[Month]]) > 0, return true.
  11. Else if d1 ≠ calDate2.[[Day]], then
    1. If sign × (d1 - calDate2.[[Day]]) > 0, return true.
  12. Return false.

4.1.18 NonISODateAdd ( calendar, isoDate, duration, overflow )

The abstract operation NonISODateAdd takes arguments calendar (a calendar type that is not "iso8601"), isoDate (an ISO Date Record), duration (a Date Duration Record), and overflow (constrain or reject) and returns either a normal completion containing an ISO Date Record or a throw completion. The operation performs processing to add duration to date in the context of the calendar represented by calendar and returns the corresponding day, month and year of the result in the ISO 8601 calendar values as an ISO Date Record. It may throw a RangeError exception if overflow is reject and the resulting month or day would need to be clamped in order to form a valid date in calendar.

All calendars follow the steps given here, which is a generalization of the precise algorithm specified in CalendarDateAdd for "iso8601".

This definition supersedes the definition provided in Temporal, 12.2.6.

It performs the following steps when called:

  1. Let parts be CalendarISOToDate(calendar, isoDate).
  2. Let y0 be parts.[[Year]] + duration.[[Years]].
  3. Let m0 be MonthCodeToOrdinal(calendar, y0, ? ConstrainMonthCode(calendar, y0, parts.[[MonthCode]], overflow)).
  4. Let endOfMonth be BalanceNonISODate(calendar, y0, m0 + duration.[[Months]] + 1, 0).
  5. Let baseDay be parts.[[Day]].
  6. If baseDay ≤ endOfMonth.[[Day]], then
    1. Let regulatedDay be baseDay.
  7. Else,
    1. If overflow is reject, throw a RangeError exception.
    2. Let regulatedDay be endOfMonth.[[Day]].
  8. Let balancedDate be BalanceNonISODate(calendar, endOfMonth.[[Year]], endOfMonth.[[Month]], regulatedDay + 7 * duration.[[Weeks]] + duration.[[Days]]).
  9. Let result be ? CalendarIntegersToISO(calendar, balancedDate.[[Year]], balancedDate.[[Month]], balancedDate.[[Day]]).
  10. If ISODateWithinLimits(result) is false, throw a RangeError exception.
  11. Return result.

4.1.19 NonISODateUntil ( calendar, one, two, largestUnit )

The abstract operation NonISODateUntil takes arguments calendar (a calendar type that is not "iso8601"), one (an ISO Date Record), two (an ISO Date Record), and largestUnit (a date unit) and returns a Date Duration Record. It determines the difference between the dates one and two using the years, months, and weeks reckoning of calendar. No fields larger than largestUnit will be non-zero in the resulting Date Duration Record.

All calendars follow the steps given here, which is a generalization of the precise algorithm specified in CalendarDateUntil for "iso8601".

This definition supersedes the definition provided in Temporal, 12.2.8.

It performs the following steps when called:

  1. Let sign be -1 × CompareISODate(one, two).
  2. If sign = 0, return ZeroDateDuration().
  3. Let years be 0.
  4. If largestUnit is year, then
    1. Let candidateYears be sign.
    2. Repeat, while NonISODateSurpasses(calendar, sign, one, two, candidateYears, 0, 0, 0) is false,
      1. Set years to candidateYears.
      2. Set candidateYears to candidateYears + sign.
  5. Let months be 0.
  6. If largestUnit is year or largestUnit is month, then
    1. Let candidateMonths be sign.
    2. Repeat, while NonISODateSurpasses(calendar, sign, one, two, years, candidateMonths, 0, 0) is false,
      1. Set months to candidateMonths.
      2. Set candidateMonths to candidateMonths + sign.
  7. Let weeks be 0.
  8. If largestUnit is week, then
    1. Let candidateWeeks be sign.
    2. Repeat, while NonISODateSurpasses(calendar, sign, one, two, years, months, candidateWeeks, 0) is false,
      1. Set weeks to candidateWeeks.
      2. Set candidateWeeks to candidateWeeks + sign.
  9. Let days be 0.
  10. Let candidateDays be sign.
  11. Repeat, while NonISODateSurpasses(calendar, sign, one, two, years, months, weeks, candidateDays) is false,
    1. Set days to candidateDays.
    2. Set candidateDays to candidateDays + sign.
  12. Return ! CreateDateDurationRecord(years, months, weeks, days).

4.1.20 NonISOCalendarDateToISO ( calendar, fields, overflow )

The abstract operation NonISOCalendarDateToISO takes arguments calendar (a calendar type that is not "iso8601"), fields (a Calendar Fields Record), and overflow (constrain or reject) and returns either a normal completion containing an ISO Date Record or a throw completion. It converts fields, which represents either a date or a year and month in the built-in calendar identified by calendar, to a corresponding representative date in the ISO 8601 calendar, subject to overflow correction specified by overflow. For reject, values that do not form a valid date cause an exception to be thrown, as described below. For constrain, values that do not form a valid date are clamped to their respective valid range.

Like RegulateISODate, the operation throws a RangeError exception when overflow is reject and the date described by fields does not exist.

Clamping an invalid date to the correct range when overflow is constrain is a behaviour specific to each calendar other than "iso8601", but all calendars follow this guideline.

This definition supersedes the definition provided in Temporal, 12.2.21.

It performs the following steps when called:

  1. Assert: fields.[[Year]], fields.[[Month]], and fields.[[Day]] are not unset.
  2. If fields.[[MonthCode]] is not unset, then
    1. Perform ? ConstrainMonthCode(calendar, fields.[[Year]], fields.[[MonthCode]], overflow).
  3. Let daysInMonth be CalendarDaysInMonth(calendar, fields.[[Year]], fields.[[Month]]).
  4. If fields.[[Day]] > daysInMonth, then
    1. If overflow is reject, throw a RangeError exception.
    2. Let day be daysInMonth.
  5. Else,
    1. Let day be fields.[[Day]].
  6. Return ? CalendarIntegersToISO(calendar, fields.[[Year]], fields.[[Month]], day).

4.1.21 NonISOMonthDayToISOReferenceDate ( calendar, fields, overflow )

The implementation-defined abstract operation NonISOMonthDayToISOReferenceDate takes arguments calendar (a calendar type that is not "iso8601"), fields (a Calendar Fields Record), and overflow (constrain or reject) and returns either a normal completion containing an ISO Date Record or a throw completion. It performs implementation-defined processing to convert fields, which represents a calendar date without a year (i.e., month code and day pair, or equivalent) in the built-in calendar identified by calendar, to a corresponding reference date in the ISO 8601 calendar as described below, subject to overflow correction specified by overflow. For reject, values that do not form a valid date cause an exception to be thrown. For constrain, values that do not form a valid date are clamped to their respective valid range as in CalendarDateToISO.

The fields of the returned ISO Date Record represent a reference date in the ISO 8601 calendar that, when converted to calendar, corresponds to the month code and day of fields in an arbitrary but deterministically chosen reference year. The reference date is the latest ISO 8601 date corresponding to the calendar date that is between January 1, 1900 and December 31, 1972 inclusive. If there is no such date, it is the earliest ISO 8601 date corresponding to the calendar date between January 1, 1973 and December 31, 2035 inclusive. The reference year is almost always 1972 (the first ISO 8601 leap year after the epoch), with exceptions for calendars where some dates (e.g. leap days or days in leap months) didn't occur during that ISO 8601 year. For example, Hebrew calendar leap month Adar I occurred in calendar years 5730 and 5733 (respectively overlapping ISO 8601 February/March 1970 and February/March 1973), but did not occur between them, so the reference year for days of that month is 1970.

This definition supersedes the definition provided in Temporal, 12.3.23.

It performs the following steps when called:

  1. Assert: fields.[[Month]] and fields.[[Day]] are not unset.
  2. Assert: If fields.[[MonthCode]] is unset, fields.[[Year]] is not unset.
  3. Let monthCode be fields.[[MonthCode]].
  4. If fields.[[Year]] is not unset, then
    1. If there exists no combination of inputs such that ! CalendarIntegersToISO(calendar, fields.[[Year]], ..., ...) would return an ISO Date Record isoDate for which ISODateWithinLimits(isoDate) is true, throw a RangeError exception.
    2. NOTE: The above step exists so as not to require calculating whether the month and day described in fields exist in user-provided years arbitrarily far in the future or past.
    3. If monthCode is not unset, then
      1. Set monthCode to ? ConstrainMonthCode(calendar, fields.[[Year]], monthCode, overflow).
    4. Let daysInMonth be CalendarDaysInMonth(calendar, fields.[[Year]], fields.[[Month]]).
  5. Else,
    1. Assert: monthCode is not unset.
    2. If calendar is "chinese" or "dangi", then
      1. NOTE: This special case handles combinations of month and day that theoretically could occur but are not known to have occurred historically and cannot be accurately calculated to occur in the future, even if it may be possible to construct a PlainDate with such combinations due to inaccurate approximations. This is explicitly mentioned here because as time goes on, these dates may become known to have occurred historically, or may be more accurately calculated to occur in the future.
      2. Let row be the row in in Table 6 with a value in the "Month Code" column matching monthCode.
      3. If the "Reference Year (Days 1–29)" column of row is "—", or fields.[[Day]] ≥ 30 and the "Reference Year (Day 30)" column of row is "—", then
        1. If overflow is reject, throw a RangeError exception.
        2. Set monthCode to CreateMonthCode(! ParseMonthCode(monthCode).[[MonthNumber]], false).
      4. Let daysInMonth be 30.
    3. Else,
      1. Let daysInMonth be the maximum number of days in the month described by monthCode in any year.
  6. If fields.[[Day]] > daysInMonth, then
    1. If overflow is reject, throw a RangeError exception.
    2. Let day be daysInMonth.
  7. Else,
    1. Let day be fields.[[Day]].
  8. If monthCode is unset, then
    1. Let fieldsISODate be ! CalendarIntegersToISO(calendar, fields.[[Year]], fields.[[Month]], day).
    2. Set monthCode to NonISOCalendarISOToDate(calendar, fieldsISODate).[[MonthCode]].
  9. Let referenceYear be the ISO reference year for monthCode and day as described above. If calendar is "chinese" or "dangi", the reference years in Table 6 are to be used.
  10. Return the latest possible ISO Date Record isoDate such that isoDate.[[Year]] = referenceYear and NonISOCalendarISOToDate(calendar, isoDate) returns a Calendar Date Record whose [[MonthCode]] and [[Day]] field values respectively equal monthCode and day.
Table 6: "chinese" and "dangi" Calendars ISO Reference Years
Month Code Reference Year (Days 1–29) Reference Year (Day 30)
M01 1972 1970
M01L — —
M02 1972
M02L 1947 —
M03 1972 "chinese": 1966
"dangi": 1968
M03L 1966 1955
M04 1972 1970
M04L 1963 1944
M05 1972
M05L 1971 1952
M06 1972 1971
M06L 1960 1941
M07 1972
M07L 1968 1938
M08 1972 1971
M08L 1957 —
M09 1972
M09L 2014 —
M10 1972
M10L 1984 —
M11 1972 1970
M11L Days 1–10: 2033
Days 11–29: 2034		 —
M12 1972
M12L — —

4.1.22 CalendarExtraFields ( calendar, fields )

The implementation-defined abstract operation CalendarExtraFields takes arguments calendar (a calendar type) and fields (a List of values from the "Enumeration Key" column of Table 19) and returns a List of values from the "Enumeration Key" column of Table 19. It characterizes calendar-specific fields that are relevant for the provided fields in the built-in calendar identified by calendar.

This definition supersedes the definition provided in Temporal, 12.2.27.

It performs the following steps when called:

  1. If calendar is not listed in the "Calendar Type" column of Table 1, return an implementation-defined value.
  2. If fields contains an element equal to year and CalendarSupportsEra(calendar) is true, then
    1. Return « era, era-year ».
  3. Return an empty List.

4.1.23 NonISOFieldKeysToIgnore ( calendar, keys )

The implementation-defined abstract operation NonISOFieldKeysToIgnore takes arguments calendar (a calendar type that is not "iso8601") and keys (a List of values from the "Enumeration Key" column of Table 19) and returns a List of values from the "Enumeration Key" column of Table 19. It performs implementation-defined processing to determine which calendar date fields changing any of the fields named in keys can potentially conflict with or invalidate, for the given calendar. A field always invalidates at least itself.

This definition supersedes the definition provided in Temporal, 12.2.28.

It performs the following steps when called:

  1. If calendar is not listed in the "Calendar Type" column of Table 1, return an implementation-defined value.
  2. Let ignoredKeys be a copy of keys.
  3. For each element key of keys, do
    1. If key is month, append month-code to ignoredKeys.
    2. If key is month-code, append month.
    3. If key is one of era, era-year, or year and CalendarSupportsEra(calendar) is true, then
      1. Append era, era-year, and year to ignoredKeys.
    4. If key is one of day, month, or month-code and CalendarHasMidYearEras(calendar) is true, then
      1. Append era and era-year to ignoredKeys.
  4. NOTE: While ignoredKeys can have duplicate elements, this is not intended to be meaningful. This specification only checks whether particular keys are or are not members of the list.
  5. Return ignoredKeys.

4.1.24 NonISOResolveFields ( calendar, fields, type )

The implementation-defined abstract operation NonISOResolveFields takes arguments calendar (a calendar type that is not "iso8601"), fields (a Calendar Fields Record), and type (date, year-month, or month-day) and returns either a normal completion containing unused or a throw completion. It performs implementation-defined processing to validate that fields (which describes a date or partial date in the built-in calendar identified by calendar) is sufficiently complete to satisfy type and not internally inconsistent, and mutates fields into acceptable input for CalendarDateToISO or CalendarMonthDayToISOReferenceDate by merging data that can be represented in multiple forms into standard fields and removing redundant fields (for example, merging [[Era]] and [[EraYear]] into [[Year]]).

This definition supersedes the definition provided in Temporal, 12.3.30.

It performs the following steps when called:

  1. Let needsYear be false.
  2. If type is date or type is year-month, set needsYear to true.
  3. If fields.[[MonthCode]] is unset, set needsYear to true.
  4. If fields.[[Month]] is not unset, set needsYear to true.
  5. Let needsDay be false.
  6. If type is date or type is month-day, set needsDay to true.
  7. If needsYear is true, then
    1. If fields.[[Year]] is unset, then
      1. If CalendarSupportsEra(calendar) is false, throw a TypeError exception.
      2. If fields.[[Era]] is unset or fields.[[EraYear]] is unset, throw a TypeError exception.
  8. If CalendarSupportsEra(calendar) is true, then
    1. If fields.[[Era]] is not unset and fields.[[EraYear]] is unset, throw a TypeError exception.
    2. If fields.[[EraYear]] is not unset and fields.[[Era]] is unset, throw a TypeError exception.
  9. If needsDay is true and fields.[[Day]] is unset, throw a TypeError exception.
  10. If fields.[[Month]] is unset and fields.[[MonthCode]] is unset, throw a TypeError exception.
  11. If CalendarSupportsEra(calendar) is true and fields.[[EraYear]] is not unset, then
    1. Let canonicalEra be CanonicalizeEraInCalendar(calendar, fields.[[Era]]).
    2. If canonicalEra is undefined, throw a RangeError exception.
    3. Let arithmeticYear be CalendarDateArithmeticYearForEraYear(calendar, canonicalEra, fields.[[EraYear]]).
    4. If fields.[[Year]] is not unset, and fields.[[Year]] ≠ arithmeticYear, throw a RangeError exception.
    5. Set fields.[[Year]] to arithmeticYear.
  12. Set fields.[[Era]] to unset.
  13. Set fields.[[EraYear]] to unset.
  14. NOTE: fields.[[Era]] and fields.[[EraYear]] are erased in order to allow a lenient interpretation of out-of-bounds values, which is particularly useful for consistent interpretation of dates in calendars with regnal eras.
  15. If fields.[[MonthCode]] is not unset, then
    1. If IsValidMonthCodeForCalendar(calendar, fields.[[MonthCode]]) is false, throw a RangeError exception.
    2. If fields.[[Year]] is not unset, then
      1. If YearContainsMonthCode(calendar, fields.[[Year]], fields.[[MonthCode]]) is true, let constrainedMonthCode be fields.[[MonthCode]]; else let constrainedMonthCode be ! ConstrainMonthCode(calendar, fields.[[Year]], fields.[[MonthCode]], constrain).
      2. Let month be MonthCodeToOrdinal(calendar, fields.[[Year]], constrainedMonthCode).
      3. If fields.[[Month]] is not unset and fields.[[Month]] ≠ month, throw a RangeError exception.
      4. Set fields.[[Month]] to month.
      5. NOTE: fields.[[MonthCode]] is intentionally not overwritten with constrainedMonthCode. Pending the "overflow" parameter in CalendarDateToISO or CalendarMonthDayToISOReferenceDate, a month code not occurring in fields.[[Year]] may cause that operation to throw. However, if fields.[[Month]] is present, it must agree with the constrained month code.
  16. Assert: fields.[[Era]] and fields.[[EraYear]] are unset.
  17. Assert: If needsYear is true, fields.[[Year]] is not unset.
  18. Assert: fields.[[Month]] is not unset.
  19. Assert: If needsDay is true, fields.[[Day]] is not unset.
  20. Return unused.

5 Normative References

The following referenced documents are required for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ECMAScript 2026 Language Specification (ECMA-262 17th Edition, or successor).
https://www.ecma-international.org/publications/standards/Ecma-262.htm

Note
Sections of this specification that depend on these references are updated on a best-effort basis, but are not guaranteed to be up-to-date with those standards.

Copyright & Software License

Software License

All Software contained in this document ("Software") is protected by copyright and is being made available under the "BSD License", included below. This Software may be subject to third party rights (rights from parties other than Ecma International), including patent rights, and no licenses under such third party rights are granted under this license even if the third party concerned is a member of Ecma International. SEE THE ECMA CODE OF CONDUCT IN PATENT MATTERS AVAILABLE AT https://ecma-international.org/memento/codeofconduct.htm FOR INFORMATION REGARDING THE LICENSING OF PATENT CLAIMS THAT ARE REQUIRED TO IMPLEMENT ECMA INTERNATIONAL STANDARDS.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  3. Neither the name of the authors nor Ecma International may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE ECMA INTERNATIONAL "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ECMA INTERNATIONAL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.