Why is EpochTimeStamp discouraged?

[domenic]

E.g., any platform API which wants to interoperate with JavaScript Date objects, would benefit from using EpochTimeStamp.

Note: Legacy platform feature

The use of EpochTimeStamp, known previously as DOMTimeStamp, is discouraged. Wherever possible use DOMHighResTimeStamp instead.

[domenic]

OK, so in WICG/cookie-store#214 I was corrected about my misunderstanding here. Apparently DOMHighResTimeStamp can also be used as an epoch-relative timestamp, and there is one single spec so far in the ecosystem that does that. (WebTransport)

At this point I think this issue is a complaint about naming and documentation. It is confusing that when we have two types, EpochTimeStamp and something else that does not have "epoch" in the name, both of them can be epoch-relative.

I guess this might be a temporary problem though. According to Webdex, Notifications API is the only user of EpochTimeStamp. (Plus I guess cookie store API, which isn't listed for some reason??) If we can remove that usage (/cc @annevk), then we can remove EpochTimeStamp entirely, and DOMHighResTimeStamp will be the only time stamp type on the platform. And the confusion will be gone.

[annevk]

I vaguely recall the numbers would get too large if you wanted to do sub-milliseconds since epoch. If that's not accurate why would we have changed how events do this?

[domenic]

Yes, that's right, but you could still use double instead of unsigned long long and have the same possible integers, just with some imperfect sub-millisecond fractional parts.

[annevk]

Makes sense. I guess Notifications could use it then, unless some users really expect integers.

But we'd definitely want to point out the problem with sub-millisecond times if you pick the epoch option in this standard.

cc @noamr

[noamr]

Makes sense. I guess Notifications could use it then, unless some users really expect integers.

But we'd definitely want to point out the problem with sub-millisecond times if you pick the epoch option in this standard.

cc @noamr

Is #150 what you're after?

[annevk]

Yeah, though I'm not sure we should close this just yet as it seems we might be able to remove EpochTimeStamp per @domenic's feedback.

[inexorabletash]

https://w3c.github.io/geolocation-api/#position_interface appears to use EpochTimeStamp as well?

And yes GeolocationPosition is in webdex hmmm

[domenic]

@dontcallmedom see above for a few WebDex failures; curious if it's easily fixable.

[dontcallmedom]

@domenic at the moment, Webdex only finds definitions that use the "canonical" link for the term; the Geolocation API uses the outdated https://www.w3.org/TR/hr-time-3/#dom-epochtimestamp link (instead of the number-less version); Webdex could probably be updated to find more matching links, but with that said, for IDL terms used in IDL fragments, WebIDLpedia is probably a more reliable source of usage since it operates in a well-defined namespace: https://dontcallmedom.github.io/webidlpedia/names/EpochTimeStamp.html does list Geolocation (and a few other cases)

[reillyeon]

I don't know why Geolocation API is linking to hr-time-3. There's nothing in the source which would indicate it is preferring it over linking to hr-time. The data-cite attribute is just set to "hr-time".

[yoavweiss]

@dontcallmedom - any idea how we could modify Geolocation to point at the numberless version?

[dontcallmedom]

hmm... re-diving into this, it sounds like this isn't specific to Geolocation, but the default in ReSpec - and sounds like it has been so for a while now - maybe worth bumping the issue there?