Normative: Temporal and Intl Era/Month Code stage 4#1044
Normative: Temporal and Intl Era/Month Code stage 4#1044
Conversation
I'm not certain that this has to move. Will discuss with ECMA-262 editors.
ptomato
force-pushed
the
temporal-stage-4
branch
from
514e7ad to
ef65d36
Compare
ptomato
changed the title
ptomato
force-pushed
the
temporal-stage-4
branch
from
ef65d36 to
4359e61
Compare
|
Updated with Intl Era/Month Code stage 4 text. |
|
One open question here is whether to refactor NumberFormat to use the GetRoundingIncrementOption and GetRoundingModeOption AOs newly added to ECMA-262. Especially roundingMode would be a bit of a refactor since we'd have to change things to use spec enums rather than strings. (Of course, this can all be done later.) |
The discussion in the ECMA-262 editor call settled on not having the same GetOption operation as in ECMA-402, so this can stay.
…ndar See the commit named "(optional) Change approach for specifying CanonicalizeCalendar" in tc39/ecma262#3759 - pending discussion with the ECMA-262 editors.
|
I've pushed a small update, keeping all changes in separate commits so it's easy to see what changed. I've reinstated GetOption and CanonicalizeUValue based on discussions in this weeks ECMA-262 editors meeting, and I've incorporated the fix for an assertion failure tc39/proposal-intl-era-monthcode#122. |
See the commit named "(review) Express epoch nanoseconds in mathematical values" in tc39/ecma262#3759 - this change is based on feedback from the ECMA-262 editors that epoch time should be specified as mathematical values.
|
Pushed a new commit addressing feedback from @fabon-f (see tc39/proposal-intl-era-monthcode#124) |
See tc39/proposal-intl-era-monthcode#126 h/t Tim Flynn
|
Pushed a new commit fixing a cut-off sentence, thanks to @trflynn89 for catching. (ref https://github.com/tc39/proposal-intl-era-monthcode/pull/126/changes#diff-7d681727fcf47dc0b9a7512a470fb0da63276c625891a5cc232d725bd12912fdR1508) |
This adjusts the language in the step in NonISOMonthDayToISOReferenceDate, clarifying that implementations must eventually use the month and day results but don't have to calculate them if the year is already out of range. h/t fabon-f See tc39/proposal-intl-era-monthcode#125
|
Pushed a new commit clarifying a sentence in NonISOMonthDayToISOReferenceDate, as per discussion in tc39/proposal-intl-era-monthcode#125. Thanks to @fabon-f for catching. |
gibson042
left a comment
gibson042
left a comment
There was a problem hiding this comment.
Some minor issues to fix and some suggestions, but nothing concerning. LGTM!
Review feedback from Richard
Review suggestion from Richard.
Review suggestions from Richard and Anba.
Review feedback from Richard.
Review suggestion from Richard.
Review suggestions from Richard.
|
I've pushed a series of commits addressing Richard's and Anba's comments. All are resolved except:
|
4 participants
Stage 4 PR for Temporal and Intl Era/Month Code.
Note, the ecmarkup linter is going to fail until ECMA-262 merges Temporal and publishes a new biblio package.
Draft 2026-02-16:
I intend to add the stage 4 PR for Intl Era/Month Code in this same PR later. For now, it is up for early feedback.2026-02-20: Now includes the stage 4 text for Intl Era/Month Code.