Change Notification.timestamp to be an unrestricted double instead

[beverloo]

Date.now() returns a value of the Number type, which maps to WebIDL's
unrestricted double. This allows timestamps in the entire range of
Date to be used, rather than just times after the unix epoch.

[beverloo]

Paging @domenic as this relates closely to whatwg/webidl#2.

The primary question I have is what we expect NaN and infinity to do. Also, we'd want this to be compatible with timestamps in other specs, but this is quite a mess right now.

• File APIs expose timestamps as long long: https://w3c.github.io/FileAPI/
• Events and Geolocation use unsigned long long: http://dev.w3.org/geo/api/spec-source.html, though this also relates to High resolution timing for events dom#23.
• Media elements expose times as double: http://dev.w3.org/html5/spec-preview/media-elements.html#media-elements
• EME, the Battery Status API and the Web Animation API: https://w3c.github.io/encrypted-media/#mediakeysession-interface, https://dvcs.w3.org/hg/dap/raw-file/default/battery/Overview.html#the-batterymanager-interface, https://w3c.github.io/web-animations/

The Web Animation API defines the behavior for NaN, so we could map that to the current time?

[domenic]

I tried to give some guidance in this regard at https://w3ctag.github.io/design-principles/#times-and-dates. In general I think all of these cases should be using DOMTimeStamp if they want epoch-compatible time, or DOMHighResTimeStamp if they want high-precision monotonic time.

We might need to change the definition or behavior of those two types though, since right now they do not account for the cases you mention. /cc @heycam

I see four options for NaN/+Infinity/-Infinity:

1. What JavaScript APIs like Date would do: just leave them as they are. If serialized to a string, use "Invalid Date".
2. What this PR does: use the current time
3. What the spec currently does (unsigned long long): use 0, i.e. the epoch.
4. What nobody seems to be doing yet: throw a RangeError. (Web IDL's [EnforceRange] uses TypeError, which seems less correct, but also acceptable.)

I don't have a strong opinion between these and would rather let people who do make the decision.

But I do feel strongly that everyone should converge on DOMTimeStamp and DOMHighResTimeStamp, so we can just update definitions in one place and not have to deal with this every time. Maybe after we get this straightened out someone can go on a pull request spree across all the repos you mention.

[heycam]

Yeah, if we want DOMTimeStamp to do something specific with NaN and +/-Infinity, we'll probably need to turn it into a real type rather than just a typedef for unsigned long long. DOMHighResTimeStamp also doesn't have unrestricted in it so throws for NaN and +/-Infinity.

Not sure I have a strong opinion on what to do with these values either, although I'm not particularly sold on NaN == current time.

[domenic]

DOMHighResTimeStamp also doesn't have unrestricted in it so throws for NaN and +/-Infinity.

The inconsistency here seems not great, at the very least. (DOMTimeStamp turns them into zero, DOMHighResTimestamp throws.)

[annevk]

@domenic the problem @beverloo had with DOMTimeStamp was not precision, but reach. It cannot be used to represent events prior to 1970.

[domenic]

It cannot be used to represent events prior to 1970.

I see. But, this is just an artificial restriction imposed by its definition. We should fix it, at the same time as we decide how to handle NaN and the infinities.

[annevk]

@beverloo any thoughts?

[annevk]

@beverloo happy new year #2 ping! 😊

[annevk]

Fixed by #60.