Re: [HighResTime] Web Worker support

So is the best solution to just pick a new epoch that's relatively recent?
Like 1/1/2013?

James


On Wed, Sep 11, 2013 at 6:37 PM, James Robinson <jamesr@google.com> wrote:

> On Wed, Sep 11, 2013 at 11:45 AM, Jatinder Mann <jmann@microsoft.com>wrote:
>
>>
>>
>> Adding originTime to the performance.now(), gives you a time value that
>> is comparable in either context. This assumes that we have enough bits in a
>> double to describe time since Jan 01 1970 in milliseconds in microsecond
>> resolution.
>>
>
> There have been a bit more than 2^40s microseconds since the unix epoch.
>  A double has 53 bits of mantissa so I think we're safe for a while.  A
> problem here is that the unix epoch is not at a fixed point relative to the
> monotonic clock.  Remember that the monotonic clock is monotonic is
> monotonic in terms of itself.  The computer that the application is running
> on may have its clock adjusted forwards or backwards while the app is
> running and in practice this happens surprisingly frequently.  This does
> not impact the monotonic clock, but it does change the delta to the unix
> epoch.  That's why window.performance.now() *has* to use a timebase
> different from the unix epoch.  What do you propose we do in this case?
>
>
>> ** **
>>
>> ** **
>>
>> Alternatively, we can define the origin for originTime to be the launch
>> of the browser.**
>>
>>
>>
> Defining the time to be relative to launch of browser allows identifying
> that browser session across multiple sites and visits by comparing the time
> to Date.now().  That'd be a really bad idea.
>
> - James
>