ISSUE-172 (Event.timeStamp): Fix Event.timeStamp [DOM3 Events]

ISSUE-172 (Event.timeStamp): Fix Event.timeStamp [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/172

Raised by: Doug Schepers
On product: DOM3 Events

Cameron McCormack <http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0069.html>:
[[

The definition of Event.timeStamp is currently:

  Used to specify the time at which the event was created in
  milliseconds relative to 1970-01-01T00:00:00Z. Due to the fact that
  some systems may not provide this information the value of timeStamp
  may be not available for all events. When not available, the value
  shall be 0.

I think we should remove the allowance for implementations to have
Event.timeStamp be 0.  It might be that implementations are running on
systems that don’t know what the actual time is, but surely JS Date is
returning something; I think it would be fine for those implementations
to assume a particular time on startup, for example.

I don’t think we need to worry about implementations that can’t even
track the progress of time.

I also think we should make Event.timeStamp be not the time at which the
event was created (the construction of the Event object?) but the time
at which the event represented by the Event object occurred.  For user
created events, we could have it be either the time that createEvent()
is called or the time that initEvent() is called (since timeStamp is
read only).
]]

Boris Zbarsky <http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0070.html>:
[[
On 10/18/10 10:41 PM, Cameron McCormack wrote:
> I also think we should make Event.timeStamp be not the time at which the
> event was created (the construction of the Event object?) but the time
> at which the event represented by the Event object occurred.

This is particularly relevant to situations in which the event is 
_about_ to occur and the UA wants to notify scripts of this.  While it 
can only guess at when the event will really occur (since the scripts 
could take a while), that still seems more useful than reporting some 
time in the past that has nothing to do with the event in question.

We (Mozilla) actually ran into this with MozBeforePaint events.  For now 
we're having the timeStamp on those represent the time when the paint is 
conceptually happening (i.e. the sampling time that will be used for 
animations when the paint happens).
]]


Boris Zbarsky <http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0071.html>:
[[
Speaking of which, I'm actually not crazy about event.timeStamp
being in milliseconds since the Epoch.  The times that operating
systems report on events (like key events and mouse events) are, for
at least some systems, I think, based on an interval timer -- a
separate timer from the clock.  (I think (hope) that it's not
particularly related to the clock, and doesn't, for example, go
backwards if the clock is changed or adjusted by NTP.  I don't
really know the details.  At the very least, events from GDK are
documented to be in milliseconds (and are), and definitely aren't in
milliseconds since the epoch; those are the values that Gecko on
Linux reports for timeStamp.)

I think interval timer times are quite useful.  I'd like to be able
to have APIs that let Web pages do things like start animations
based on the time of the mouse or key event that triggered them,
which I think should make them appear more responsive, even if it
really takes them a little time to get started.

If we have to report a time in milliseconds since the epoch, we'd be
unlikely to be able to correctly report the time the key was
pressed; we'd have to report the time Gecko processed the key event,
which might be a bit later.
]]

Received on Wednesday, 20 October 2010 17:06:49 UTC