W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2012

Re: DOMHighResTimeStamps in DOM events, use cases

From: Robert Flack <flackr@chromium.org>
Date: Wed, 10 Oct 2012 12:45:03 -0400
Message-ID: <CAJh39TMCMX1tT_5JJaiK_if08Ty6rNX9pKfe9UR_Nqf1nFiqvw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Anne van Kesteren <annevk@annevk.nl>, Pablo Garaizar Sagarminaga <garaizar@deusto.es>, www-dom@w3.org, Jonas Sicking <jonas@sicking.cc>
On Wed, Oct 10, 2012 at 12:09 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 10/10/12 6:31 AM, Anne van Kesteren wrote:
>
>> I'm not quite sure I follow. I guess the main problem would be that
>> you suddenly have a decimal in there which is not what everyone
>> expects at the moment. Boris, Jonas, opinions? (Context is whether or
>> not we should have a new attribute on events indicating when the
>> system dispatched them or if we should just change Event.timeStamp.)
>>
>
> The only relevant comment I have is that at one point Gecko temporarily
> tried making Date.now() return sub-millisecond times, with a decimal. This
> broke things all over that were concatenating the return value of
> Date.now() with some constant strings to produce things like "unique" class
> names and whatnot.  Turns out once your class name contains a '.' you have
> to be careful with your CSS.  ;)
>
> Anyway, there is probably nonzero risk of this being a problem with
> Event.timeStamp.  Not sure how high the risk is.
>
> The other possible risk is that high-res time and current Event.timeStamp
> have a different 0 point, right?
>
>
Yes, this is the reason for not changing Event.timeStamp. The reasons for
the different 0 point are described in the
http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.htmldraft
(i.e. why we can't use 1970 and why it's document load start for
security).


>
>  So would Event.systemTime be time since epoch as well? I cannot
>> actually find an exact definition anywhere in the previous emails and
>> I'm not sure what
>> document()->loader()->timing()**->**convertMonotonicTimeToZeroBase**
>> dDocumentTime()
>> does ;-) (I asked on #webkit, but people were asleep.)
>>
>
> Presumably converts to time with 0 set to document load start.  So the
> same timescale as performance.now().
>
>
This also doesn't take in a 1970 epoch timestamp (which Event.timeStamp
returns). The timestamp comes in as a system uptime timestamp as this is
the only time we can measure accurately as a monotonically increasing value
(i.e. user can change the system clock, NTP adjustments, etc).


> -Boris
>
>
>
Received on Wednesday, 10 October 2012 16:45:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 10 October 2012 16:45:39 GMT