Normative: Ignore "islamic-rgsa" calendar in DateTimeFormat #99

ben-allen · 2025-12-04T13:12:42Z

Following guidance in issue #29 conversation, this PR causes the value of "ca" to be removed from the _options_ of CreateDateTimeFormat when the value of _options_.[[ca]] is "islamic-rgsa". This calendar matches no calendar in actual use and should be ignored.

fix #94

Following guidance in [issue tc39#29 conversation](tc39#29 (comment)), this PR causes the value of `"ca"` to be removed from the `_options_` of `CreateDateTimeFormat` when the value of `_options_.[[ca]]` is "islamic-rgsa". This calendar matches no calendar in actual use and should be ignored.

ptomato

Based on the discussion from yesterday's TG2 I think here's what we need to change in this PR:

delete the added text, it's no longer relevant
delete the "islamic-rgsa" from the If-clause a few lines lower down
change the fallbackCalendar and CanonicalizeUValue lines to simply "Set resolvedCalendar to "islamic-tbla"."
in AvailableCalendars, change "The List must include" to "The List must consist of"

sffc · 2025-12-09T02:21:01Z

TG2 discussion notes: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-12-04.md#normative-ignore-islamic-rgsa-calendar-in-datetimeformat-99

sffc · 2025-12-09T02:25:00Z

Additional notes: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-12-04.md#revisit-normative-ignore-islamic-rgsa-calendar-in-datetimeformat-99

See meeting notes: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-12-04.md#normative-ignore-islamic-rgsa-calendar-in-datetimeformat-99 https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-12-04.md#revisit-normative-ignore-islamic-rgsa-calendar-in-datetimeformat-99

ben-allen · 2025-12-10T17:17:05Z

Updated per @ptomato's suggestion

ptomato

Sorry, didn't occur to me before, but I think this section also needs to change. At least "even if supporting only the calendars from Table 1" needs to be rephrased, since it's now required to support only the calendars from Table 1.

Possibly something like "This list may include calendar types not listed in Table 1"?

See: tc39/proposal-intl-era-monthcode#99

…4786) See: tc39/proposal-intl-era-monthcode#99

…ion for internal slots of Intl.DateTimeFormat constructor

ptomato

I just realized we additionally need to comb through the proposal and remove any language that says "If calendar is not listed in Table 1, return an implementation-defined value" — that will no longer be allowed.

…bleCalendars`, no longer "must include" all the calendar types in Table 1 (Calendar types described in CLDR), but instead must entirely consist of the calendar types in Table 1. As a result, `AvailableCalendars` and two other AOs: * `CalendarExtraFields` * `NonISOFieldKeysToIgnore` are likewise not implementation-defined. Steps in these AOs returning implementation-defined values for calendar types not in Table 1 have been removed.

ben-allen · 2025-12-12T23:23:39Z

As of the last commit this PR would fix #94

hsivonen · 2025-12-19T11:24:16Z

Is there anything in particular blocking this from landing?

ptomato · 2026-01-06T20:30:05Z

It needs to be presented to TG1, no?

hsivonen

Thanks!

gibson042 · 2026-01-10T00:01:45Z

spec.emu

      <dl class="header">
        <dt>description</dt>
-        <dd>The returned List is sorted according to lexicographic code unit order, and contains unique calendar types in canonical form (<emu-xref href="#sec-calendar-types"></emu-xref>) identifying the calendars for which the implementation provides the functionality of Intl.DateTimeFormat objects, including their aliases (e.g., <del>either</del> both <del>or neither of</del> *"islamicc"* and *"islamic-civil"*). The List must include <del>*"iso8601"*</del><ins>the Calendar Type value of every row of <emu-xref href="#table-calendar-types"></emu-xref>, except the header row</ins>.</dd>
+        <dd>The returned List is sorted according to lexicographic code unit order, and contains unique calendar types in canonical form (<emu-xref href="#sec-calendar-types"></emu-xref>) identifying the calendars for which the implementation provides the functionality of Intl.DateTimeFormat objects, including their aliases (e.g., <del>either</del> both <del>or neither of</del> *"islamicc"* and *"islamic-civil"*). The List must consist of <del>*"iso8601"*</del><ins>the Calendar Type value of every row of <emu-xref href="#table-calendar-types"></emu-xref>, except the header row</ins>.</dd>


"consist of" implies that the returned list must be constrained to the following table, which is not the case.

Suggested change

<dd>The returned List is sorted according to lexicographic code unit order, and contains unique calendar types in canonical form (<emu-xref href="#sec-calendar-types"></emu-xref>) identifying the calendars for which the implementation provides the functionality of Intl.DateTimeFormat objects, including their aliases (e.g., <del>either</del> both <del>or neither of</del> *"islamicc"* and *"islamic-civil"*). The List must consist of <del>*"iso8601"*</del><ins>the Calendar Type value of every row of <emu-xref href="#table-calendar-types"></emu-xref>, except the header row</ins>.</dd>

<dd>The returned List is sorted according to lexicographic code unit order, and contains unique calendar types in canonical form (<emu-xref href="#sec-calendar-types"></emu-xref>) identifying the calendars for which the implementation provides the functionality of Intl.DateTimeFormat objects, including their aliases (e.g., <del>either both or neither of</del><ins>both</ins> *"islamicc"* and *"islamic-civil"*). The List must include <del>*"iso8601"*</del><ins>the Calendar Type value of every row of <emu-xref href="#table-calendar-types"></emu-xref>, except the header row</ins>.</dd>

gibson042 · 2026-01-10T00:06:53Z

spec.emu

        1. Assert: IsValidMonthCodeForCalendar(_calendar_, _monthCode_) is *true*.
        1. If YearContainsMonthCode(_calendar_, _arithmeticYear_, _monthCode_) is *true*, return _monthCode_.
        1. If _overflow_ is ~reject~, throw a *RangeError* exception.
-        1. If _calendar_ is not listed in the Calendar Type column of <emu-xref href="#table-calendar-types"></emu-xref>, return an implementation-defined value.


Why are these implementation-defined steps being removed? AFAIK, they are necessary to retain for implementations supporting non-required calendar types to still be conforming.

1. If _calendar_ is not listed in the Calendar Type column of <emu-xref href="#table-calendar-types"></emu-xref>, return an implementation-defined value.

That was the conclusion from TG2, that implementations supporting non-required calendar types should not be conforming: https://docs.google.com/document/d/1AIsV-xXMWZ6fUX27Gw1UsIswmfcMZEjhdz3adla8lso/edit?tab=t.0#heading=h.vtb7plo5cjtx

That was a point raised, but AFAICT not a conclusion. But at any rate, the contents of this PR currently lack internal consistency regarding whether or not the list is exhaustive.

spec.emu

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

sffc · 2026-01-10T05:34:26Z

spec.emu


      <ul>
-        <li><ins>[[LocaleData]].[[&lt;_locale_>]].[[ca]] must be a List consisting of calendar types. Specifically, even if supporting only the calendars from <emu-xref href="#table-calendar-types"></emu-xref>, the list may also include *"islamic"* and *"islamic-rgsa"*.</ins></li>
+        <li><ins>[[LocaleData]].[[&lt;_locale_>]].[[ca]] must be a List consisting of calendar types. It may include calendar types not listed in <emu-xref href="#table-calendar-types"></emu-xref>.</ins></li>


No, any browser calendar values from locales should only be supported Temporal calendars. An explicit -u-ca need not be supported, but the CLDR data needs to all be supported.

sffc added this to ECMA-402 Meeting Topics Dec 4, 2025

sffc moved this to Priority Issues in ECMA-402 Meeting Topics Dec 4, 2025

ryzokuken force-pushed the issue-29-hijri-calendars branch from cff02fb to 3ade73a Compare December 4, 2025 17:05

ryzokuken changed the title ~~Normative: Ignore "islamic-rgsa" calendar option~~ Normative: Ignore "islamic-rgsa" calendar in DateTimeFormat Dec 4, 2025

ptomato requested changes Dec 6, 2025

View reviewed changes

ben-allen force-pushed the issue-29-hijri-calendars branch from 3ade73a to be6c4b1 Compare December 10, 2025 17:16

sffc approved these changes Dec 10, 2025

View reviewed changes

ptomato requested changes Dec 11, 2025

View reviewed changes

anba added a commit to anba/test262 that referenced this pull request Dec 12, 2025

Ensure all required and no additional calendar types are supported

9c5fc41

See: tc39/proposal-intl-era-monthcode#99

anba mentioned this pull request Dec 12, 2025

Ensure all required and no additional calendar types are supported tc39/test262#4786

Merged

ptomato pushed a commit to tc39/test262 that referenced this pull request Dec 12, 2025

Ensure all required and no additional calendar types are supported (#…

947fee3

…4786) See: tc39/proposal-intl-era-monthcode#99

Removed reference to islamic and islamic-rgsa calendars from sect…

ff58c24

…ion for internal slots of Intl.DateTimeFormat constructor

ptomato requested changes Dec 12, 2025

View reviewed changes

ben-allen mentioned this pull request Dec 12, 2025

Editorial: Change type of several AOs from "implementation-defined abstract operation" to just "abstract operation" #103

Open

ptomato approved these changes Dec 12, 2025

View reviewed changes

sffc moved this from Priority Issues to Previously Discussed in ECMA-402 Meeting Topics Jan 8, 2026

ben-allen moved this from Previously Discussed to Priority Issues in ECMA-402 Meeting Topics Jan 8, 2026

hsivonen approved these changes Jan 8, 2026

View reviewed changes

gibson042 suggested changes Jan 10, 2026

View reviewed changes

Update spec.emu

5969b9e

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

sffc reviewed Jan 10, 2026

View reviewed changes

Normative: Ignore "islamic-rgsa" calendar in DateTimeFormat #99

Are you sure you want to change the base?

Normative: Ignore "islamic-rgsa" calendar in DateTimeFormat #99

Conversation

ben-allen commented Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ptomato left a comment

Choose a reason for hiding this comment

Uh oh!

sffc commented Dec 9, 2025

Uh oh!

sffc commented Dec 9, 2025

Uh oh!

ben-allen commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ptomato left a comment

Choose a reason for hiding this comment

Uh oh!

ptomato left a comment

Choose a reason for hiding this comment

Uh oh!

ben-allen commented Dec 12, 2025

Uh oh!

hsivonen commented Dec 19, 2025

Uh oh!

ptomato commented Jan 6, 2026

Uh oh!

hsivonen left a comment

Choose a reason for hiding this comment

Uh oh!

gibson042 Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

gibson042 Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

ptomato Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

gibson042 Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sffc Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ben-allen commented Dec 4, 2025 •

edited

Loading

ben-allen commented Dec 10, 2025 •

edited

Loading