Add the HostSystemUTCEpochNanoseconds abstract operation

[Ms2ger]

See tc39/proposal-temporal#1654

• At least two implementers are interested (and none opposed):
  • TC39 Stage 3 (for real now)
• Tests are written and can be reviewed and commented upon at:
  • Plenty of tests in test262; I don't think there's a way to test the specific changes in this PR.
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/42201538
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1839673
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=223166
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/index.html ( diff )
/infrastructure.html ( diff )
/references.html ( diff )
/webappapis.html ( diff )

[annevk]

I guess this was not entirely obvious in the other PR, but this needs to directly invoke https://w3c.github.io/hr-time/#dfn-current-high-resolution-time. The primitives defined in that specification are what all web platform specifications hook into.

I also wonder if we can get more context on nsMinInstant and nsMaxInstant as performance.now() and other APIs don't have that.

(I do think it makes sense for HTML to define the implementation of the hook as HTML generally manages the hooks.)

[Ms2ger]

I guess this was not entirely obvious in the other PR, but this needs to directly invoke https://w3c.github.io/hr-time/#dfn-current-high-resolution-time. The primitives defined in that specification are what all web platform specifications hook into.

That returns a relative time stamp like performance.now(), not a time relative to the unix epoch. The "current wall time" seems to make more sense, especially since HRT already says this is the clock ES uses.

I also wonder if we can get more context on nsMinInstant and nsMaxInstant as performance.now() and other APIs don't have that.

Temporal APIs "only" support the time range from JS Date (100 million days around the Unix epoch). See https://tc39.es/proposal-temporal/#sec-temporal-instant-range

[annevk]

Oh right, we should use https://w3c.github.io/hr-time/#dfn-epoch-relative-timestamp coupled with https://w3c.github.io/hr-time/#dfn-coarsen-time then. @noamr do you know why the former isn't prefixed with unsafe?

[Ms2ger]

I think "epoch-relative timestamp" already returns a value at whole-millisecond precision, so no point in coarsening it by a few microseconds. Incidentally, this also makes it unsuitable for Temporal.

[noamr]

I think "epoch-relative timestamp" already returns a value at whole-millisecond precision, so no point in coarsening it by a few microseconds. Incidentally, this also makes it unsuitable for Temporal.

It returns a millisecond value at double precision. Still, probably not accurate enough for Temporal.

[annevk]

I see, the division of labor between hr-time and HTML doesn't strike me as ideal, but I also don't have a concrete suggestion. @jyasskin do you have any thoughts about this? I see that "epoch-relative timestamp" wasn't refactored to return a duration.

[Ms2ger]

I think "epoch-relative timestamp" already returns a value at whole-millisecond precision, so no point in coarsening it by a few microseconds. Incidentally, this also makes it unsuitable for Temporal.

It returns a millisecond value at double precision. Still, probably not accurate enough for Temporal.

Are you reading "the number of milliseconds" as returning a fractional value? That doesn't seem like the obvious interpretation to me.

[noamr]

I think "epoch-relative timestamp" already returns a value at whole-millisecond precision, so no point in coarsening it by a few microseconds. Incidentally, this also makes it unsuitable for Temporal.

Apologies, you are correct.

[jyasskin]

I left "epoch-relative timestamp" as the interface to existing callers, so that I could land the refactoring without updating all callers. My recommendations for new users are in https://w3c.github.io/hr-time/#sec-tools, and I think this patch follows them.

In https://w3c.github.io/hr-time/#dfn-epoch-relative-timestamp, I think "the number of milliseconds" is ambiguous about whether it rounds to the nearest integer (safe) or returns a full-precision double (unsafe), and I should send a patch to say that it rounds.

[jyasskin]

It looks like "epoch-relative timestamp" was only used in 1 spec, so instead of clarifying it, w3c/hr-time#153 suggests to delete it.

[domenic]

Looks good with nits. I tried fixing the nits myself and pushing, but I guess "allow edits from maintainers" was not checked or something; it gave me an error.

Indeed, I guess if Temporal is not really a ship-worthy proposal, we should not merge this yet. We generally include features in HTML that browsers are willing to ship, and somehow for this TC39 stage 3 feature I guess that is not the case?

So, I guess we'll mark this as "do not merge yet" until we get the PR template filled out, and the relevant marker removed from the Temporal spec. But if it helps unblock the TC39 side of things, please don't feel blocked on HTML editor review anymore. From our perspective it looks good, modulo the editorial nits.

[Ms2ger]

Thanks! I'll ask @ptomato to clarify the shippability here.

I guess https://github.com/orgs/community/discussions/5634 is why you couldn't edit directly - I keep forgetting about that.

[ptomato]

Follow tc39/proposal-temporal#1450 for the status of the blocker on shippability. The current agreement is that Temporal remains behind a flag until this proposed standard for the calendar and time zone annotations used in serialization of Temporal objects is ratified by the IETF.

[nicolo-ribaudo]

Note: tc39/proposal-temporal#1450, which was marked as a blocked for this PR, has been solved.

[annevk]

Indeed, as per #9038 (review) filling out the PR template appears to be what remains here.

[annevk]

Thanks for updating @Ms2ger!

I'm comfortable with landing this given the state of things explained in tc39/proposal-temporal#2628. @domenic?

[annevk]

I've put this in my calendar to merge on June 19. Happy to do it sooner if @domenic or @syg can confirm things are okay from their side.