[DOM3Events] Event.timeStamp should be interval time rather than epoch-based

http://www.w3.org/TR/2012/WD-DOM-Level-3-Events-20120906/#events-event-type-timeStamp
says that Event.timeStamp is of time DOMTimeStamp, gives a time
in milliseconds since the epoch, and represents the time the event
was created.

This doesn't match what many operating systems report as times for
click and mouse events.  It also doesn't match what Mozilla
implements for Event.timeStamp, since we report the concept that the
system gives us.

I think Event.timeStamp should use a concept similar to
DOMHighResTimeStamp as defined in http://www.w3.org/TR/hr-time/
instead, except it may for compatibility need to be an integral type
rather than a floating-point type, and it should be defined to be
the time that the event occurred (or will occur; see
http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0070.html ).

This has the advantages that:

 (1) The event timeStamp can report the non-lagged timeStamp that
 comes from the operating environment (which is, I believe,
 generally based on a monotonic clock) rather than a
 seconds-since-the-epoch time that might need to be created later.
 This has the advantage that authors using the timeStamp of an event
 to do things like create animation effects whose timing is based on
 the time of the event (for improved responsiveness) will get
 accurate timing.

 (2) Authors using event times will have all the other advantages of
 time stamps that are based on a monotonic clock; i.e., they won't
 encounter bugs when there's a system clock adjustment.

There was previously some discussion of this issue in
http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0071.html and
http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0072.html .

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Thursday, 20 September 2012 20:35:57 UTC