DOMTimeStamp confusion

[domenic]

DOMTimeStamp has a few questionable things I was hoping to get cleared up:

• Because it's unsigned long long, it cannot represent dates before 1970. Is that a desired property for a timestamp?
• It says that it can be either absolute or relative. Do any specs use it for relative timestamps? I have not found any in a quick Google search.
• Why does it exist? This is probably part of a larger conversation regarding the utility of WebIDL's various number types, but, it was pretty confusing to find DOMTimeStamp when I could have just found unsigned long long (or ideally number, which would fix the 1970 restriction).

I'd love to discuss the general problem of number types in WebIDL after I've had time to put together a more concrete proposal, but I am wondering if there's anything we can do to clean up the DOMTimeStamp corner of this mess.

[heycam]

DOMTimeStamp exists because it was in DOM 2 Core and was used as the type of Event.timeStamp. Is it being used elsewhere?

We could redefine it to being a double and thus a JS Number value, and give it the same semantics as a JS Date's value, but relative to the current timezone.

[heycam]

What people want from a timestamp type is a good question to ask, though. :)

[travisleithead]

EME is now also trying to use DOMTimeStamp (for absolute time comparisons, I believe). w3c/encrypted-media#59

[travisleithead]

Can we recommend to the EME folks to just use unsigned long long for now?

[domenic]

No, we should recommend using the correct types and then we can fix up the type definitionsin one place to benefit everyone.

[annevk]

DOM no longer uses this. Geolocation API does though.

[marcoscaceres]

We could transition Geolocation to using a relative timestamp (or just inline "unsigned long long" over on Geo to get rid of the typedef). I'm pretty open to whatever folks think is best. My worry from the geo side is that devs will be relying on the current timestamp to make decisions about asking for a position refresh.

[annevk]

I think it's fine to rely on this, though it should maybe move out of IDL. Perhaps we should put all web platform time things in hr-time to consolidate on that and also have a single place to make recommendations with regards which abstraction to pick.

cc @yoavweiss