Skip to content

Commit ba3d9b4

Browse files
committedSep 30, 2024
Editorial: Recommend "remapping" for dates exceeding era year bounds
Fixes tc39#2865
1 parent 8c70250 commit ba3d9b4

File tree

2 files changed

+7
-3
lines changed

2 files changed

+7
-3
lines changed
 

‎polyfill/lib/calendar.mjs

-3
Original file line numberDiff line numberDiff line change
@@ -1461,9 +1461,6 @@ const makeHelperGregorian = (id, originalEras) => {
14611461
({ code, names = [] }) => code === era || ES.Call(ArrayPrototypeIncludes, names, [era])
14621462
]);
14631463
if (!matchingEra) throw new RangeErrorCtor(`Era ${era} (ISO year ${eraYear}) was not matched by any era`);
1464-
if (eraYear < 1 && matchingEra.reverseOf) {
1465-
throw new RangeErrorCtor(`Years in ${era} era must be positive, not ${year}`);
1466-
}
14671464
if (matchingEra.reverseOf) {
14681465
year = matchingEra.anchorEpoch.year - eraYear;
14691466
} else {

‎spec/calendar.html

+7
Original file line numberDiff line numberDiff line change
@@ -1348,6 +1348,13 @@ <h1>
13481348
<emu-note>
13491349
In some cases, verifying the internal consistency of fields requires accessing the data from other fields, such checking _fields_.[[MonthCode]] *"M06"* against _fields_.[[Month]] 7 in the Hebrew calendar (which are consistent if and only if _fields_ identifies a year that includes leap month Adar I).
13501350
</emu-note>
1351+
<emu-note>
1352+
<p>When the fields of _fields_ are inconsistent with respect to a non-~unset~ _fields_.[[Era]], it is recommended that _fields_.[[Era]] and _fields_.[[EraYear]] be updated to resolve the inconsistency by appropriate interpretation of out-of-bounds values (rather than throwing a *RangeError*), which is particularly useful for consistent interpretation of dates in calendars with regnal eras.</p>
1353+
<ul>
1354+
<li>In the Gregorian calendar, a non-positive [[EraYear]] should be replaced with a positive [[EraYear]] corresponding with extension of the era into its complement and [[Era]] should be updating accordingly (such that Common Era [[EraYear]] 0 is updated to Before Common Era [[EraYear]] 1, Before Common Era [[EraYear]] -1 is updated to Common Era [[EraYear]] 2, etc.).</li>
1355+
<li>In the Japanese calendar, when _fields_.[[Era]] is not ~unset~ and the date represented by _fields_ is not within the bounds of that era, _fields_.[[Era]] should be updated to the appropriate containing era for that date (for example, because the transition from Heisei era [[EraYear]] 31 to Reiwa era [[EraYear]] 1 took place on May 1 of [[Year]] 2019, Heisei era [[EraYear]] 32 should be updated to Reiwa era [[EraYear]] 2, Reiwa era [[EraYear]] 1 [[Month]] 1 should be updated to Heisei era [[EraYear]] 31 [[Month 1]], etc.).</li>
1356+
</ul>
1357+
</emu-note>
13511358
<emu-note>
13521359
When _type_ is ~month-day~ and _fields_.[[Month]] is not ~unset~, it is recommended that all built-in calendars other than the ISO 8601 calendar require a disambiguating year (e.g., either _fields_.[[Year]] or _fields_.[[Era]] and _fields_.[[EraYear]]), regardless of whether or not _fields_.[[MonthCode]] is also ~unset~. The ISO 8601 calendar allows _fields_.[[Year]] to be ~unset~ in this case because it is a special default calendar that is permanently stable for automated processing.
13531360
</emu-note>

0 commit comments

Comments
 (0)
Please sign in to comment.