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.
514e7ad to
ef65d36
Compare
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) |
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.