Normative: add Temporal - #3759
Conversation
ptomato
left a comment
There was a problem hiding this comment.
Self-reviewing to point out places where you might particularly have questions/comments and places where the one-document approach would simplify things.
We may want to additionally look at https://tc39.es/ecma262/#sec-date-time-string-format. Most likely this can be simplified with Temporal stuff, or turned into a grammar using the building blocks from Temporal's RFC9557 grammar.
| In time zone aware implementations, a primary time zone identifier is a Zone name, and a non-primary time zone identifier is a Link name, respectively, in the IANA Time Zone Database except as specifically overridden by AvailableNamedTimeZoneIdentifiers as specified in the ECMA-402 specification. | ||
| Implementations that do not support the entire IANA Time Zone Database are still recommended to use IANA Time Zone Database names as identifiers to represent time zones. | ||
| </p> | ||
| <p>These identifiers are described by the following grammar.</p> |
There was a problem hiding this comment.
This grammar would be deduplicated into Temporal's RFC 9557 grammar if we go the same-document route.
| UTC offsets that represent offset time zone identifiers, or that are intended for interoperability with ISO 8601, use only hours and minutes and are specified by |UTCOffset[~SubMinutePrecision]|. | ||
| UTC offsets that represent the offset of a named time zone can be more precise, and are specified by |UTCOffset[+SubMinutePrecision]|. | ||
| </p> | ||
| <p>These formats are described by the following grammar.</p> |
There was a problem hiding this comment.
This grammar would also be deduplicated into Temporal's RFC 9557 grammar.
| </emu-clause> | ||
| </emu-clause> | ||
|
|
||
| <emu-clause id="sec-iso-date-records"> |
There was a problem hiding this comment.
These three sections on ISO Date Records, Time Records, and ISO Date-Time Records would go into a Temporal section if we put Temporal in the same document. But they're needed in ECMA-262 for AOs like GetNamedTimeZoneEpochNanoseconds and GetNamedTimeZoneOffsetNanoseconds.
b7627f5 to
283e9b8
Compare
|
As for the "esmeta yet phrases detection" job there seem to be two main issues:
I'm puzzled about that since both constructions seem to be used elsewhere in the spec. Am I doing something wrong here or do I need to add these manually to a skip list? Once those are resolved I can dig into the remaining items turned up by ESMeta. |
This commit makes changes to ECMA-262 AOs that are needed for Temporal regardless of whether it lands in a separate document.
283e9b8 to
ccbb91e
Compare
This adds the rest of the Temporal proposal, organizing it into the "Numbers and Dates" section. Some of the sections added in the previous commit are moved into Temporal sections. The existing section on "Time Zone Identifiers", used both by Date and Temporal, is moved into its own section under "Numbers and Dates". Most of the proposal is kept in separate temporal/*.emu files, included with `<emu-import>` tags. This is an arbitrary choice and can be done differently if so desired.
ptomato
left a comment
There was a problem hiding this comment.
More self-review with comments on things you may want to look at. I'm planning to join the editor call on Monday 23 Feb, so we can talk through this PR live.
Additional comments not tied to a particular place in the PR:
- We may want to refactor/rewrite 21.4.1.32 Date Time String Format to use the new grammar.
- Probably one of the main things to talk about in the editor call is "how to structure the sections". I've put most everything as subsections of the "Numbers and Dates" section. Maybe it makes sense to split that up into two toplevel sections, "Numbers" and "Dates"? Here's what the second-level outline looks like now:
| <emu-clause id="sec-canonicalizeuvalue" type="abstract operation"> | ||
| <h1> | ||
| CanonicalizeUValue ( | ||
| _ukey_: a Unicode locale extension sequence key defined in <a href="https://unicode.org/reports/tr35/#Key_And_Type_Definitions_">Unicode Technical Standard #35 Part 1 Core Section 3.6.1 Key and Type Definitions</a>, | ||
| _uvalue_: a String, | ||
| ): a String | ||
| </h1> | ||
| <dl class="header"> | ||
| <dt>description</dt> | ||
| <dd>The returned String is the canonical and case-regularized form of _uvalue_ as a value of _ukey_.</dd> | ||
| </dl> | ||
| <emu-alg> | ||
| 1. Let _lowerValue_ be the ASCII-lowercase of _uvalue_. | ||
| 1. Let _canonicalized_ be the String value resulting from canonicalizing _lowerValue_ as a value of key _ukey_ per <a href="https://unicode.org/reports/tr35/#processing-localeids">Unicode Technical Standard #35 Part 1 Core, Annex C LocaleId Canonicalization Section 5 Canonicalizing Syntax, Processing LocaleIds</a>. | ||
| 1. NOTE: It is recommended that implementations use the 'u' extension data in <code>common/bcp47</code> provided by the Common Locale Data Repository (available at <a href="https://cldr.unicode.org/">https://cldr.unicode.org/</a>). | ||
| 1. Return _canonicalized_. | ||
| </emu-alg> | ||
| </emu-clause> |
There was a problem hiding this comment.
CanonicalizeUValue is debatable whether it should be included here. It's moved from ECMA-402 into here, but is only used for CanonicalizeCalendar, to show that if the implementation supports multiple calendars, their identifiers should be canonicalized in the way specified in UTS#35.
An alternative would be to override CanonicalizeCalendar in ECMA-402 instead, and provide a skeleton CanonicalizeCalendar here which does something like "If id is some case-insensitive form of "iso8601", return "iso8601", else throw".
There was a problem hiding this comment.
I've included what this would look like, in an additional commit named "(optional) Change approach for specifying CanonicalizeCalendar".
|
Hi! I'm implementing Temporal in engine262. I'd like to know if all changes made here will be synced to the Temporal repo, or if the repo will be stale and all new changes will be made here. |
|
I'm not planning to sync changes back to the Temporal repo, unless someone really wants that. |
|
The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/3759 and as multiple pages at https://tc39.es/ecma262/pr/3759/multipage . |
|
Notes from editor call:
|
Split the "Numbers and Dates" section into "Numbers and Mathematical Functions" and "Dates and Temporal".
…rmat 24:00 is not supported in the current (2019) edition of ISO 8601, unlike the 2004 edition which we previously cited in the bibliography. Also update the note about a standard for time zone names not existing; this exists now with RFC 9557.
The desired convention going forward ("Stop Coercing Things") is too
different from the ECMA-402 options conventions, so it doesn't make
sense to share GetOption with ECMA-402.
The reversion of base64 changes can be squashed with "Normative:
Temporal stage 4, part 1"
Minor editorial point, reads better when the operands are in the same order as the AO's arguments.
[[EpochNanoseconds]] should be a mathematical value instead of a BigInt, both as a matter of convention and because implementations are likely to use a different type than their internal BigInt type. Bikeshedding welcome on the type name. I went with "An epoch nanoseconds value", but "an exact time", "an epoch time", etc., are possibilities.
Can be squashed with "Normative: Temporal stage 4, part 2"
…rings Instead of |DateYear| and |DateDay|. Naming the parse node one level down from the goal may make it easier to understand what needs to be implemented.
As discussed during the editors meeting, this commit shows what it'd look like if we changed AvailableCalendars and CanonicalizeCalendar to work more like time zones, where we give the specification assuming that only the minimum is supported. CanonicalizeUValue would then stay in ECMA-402 where it originated, and ECMA-402 would gain an override of CanonicalizeCalendar (it already has one for AvailableCalendars).
|
I've added commits addressing all the things we discussed in Monday's editor call. (To make it easy to see what changed, I'll refrain from squashing or force-pushing until it comes time to merge.) I tried to request another preview but the job failed with a 403 on |
| <dd>Given two Temporal units, it returns the larger of the two units.</dd> | ||
| </dl> | ||
| <emu-alg> | ||
| 1. For each row of <emu-xref href="#table-temporal-units"></emu-xref>, except the header row, in table order, do |
There was a problem hiding this comment.
Oh I really don't like this. Not only is it indirecting via this table, but it now imposes this implicit constraint that the table is ordered in descending unit duration.
|
Alright, I'm going to stop there with my review for now. I'll continue after my current comments have been addressed and the PR has been rebased. |
Thanks for the work you've put in so far. I'll start addressing and/or replying to these next week. By the way, when I rebase the PR, would you prefer that I keep the current commit stack, and keep adding new commits for each addressed comment on top of that? Or squash the current stack before adding new commits? |
|
Squash the current commits and make new commits on top of that, please. |
|
Before addressing the comments, I've opened #3927, #3928, #3929, and #3930 implementing requests from this review thread that apply regardless of Temporal. Hopefully those can be either merged quickly or closed quickly, then this PR will contain fewer non-Temporal-related changes. Another candidate for a separate PR is a |
The canonical links for RFCs are of the form https://rfc-editor.org/info/rfcNNNN. The datatracker.ietf.org links were used for tracking drafts, and should not be in normative text. tc39#3759 (comment)
Stage 4 PR for Temporal.
Draft 2026-02-16:
This currently includes only the changes to ECMA-262 that would need to be made if putting Temporal in a separate document. It does not yet include the Temporal Object itself. I've posted this for early feedback since I expect these parts will be what attracts the most review comments anyway. I'll update this later on to include the rest of the proposal.2026-02-20: This now includes the rest of the Temporal proposal.