Re: DOMHighResTimeStamps in DOM events, use cases

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
>
>
>