Re: [HighResTime] Web Worker support

That works for me.

We should probably call out that it could be negative if the shared worker
was started before this instance of the page loaded.

James


On Mon, Sep 16, 2013 at 4:45 PM, James Robinson <jamesr@google.com> wrote:

> If the use case is to correlate window.performance.now() times within a
> worker to that in a parent page, why not expose the worker creation time in
> the parent page's epoch to the parent?  This would be the difference in
> epochs between the parent and worker page's window.performance.now() times.
>  The parent could postMessage() this to a child or to other pages if it
> liked.
>
> - James
>
>
> On Mon, Sep 16, 2013 at 4:34 PM, Jatinder Mann <jmann@microsoft.com>wrote:
>
>>  To avoid the privacy issue, seems like we may need to go with a new
>> epoch. However, wouldn’t using a new epoch still suffer from the issue of
>> the clock being adjusted while the application is running?****
>>
>> ** **
>>
>> I don’t have any concerns with using January 01 2013 as a new epoch
>> (better than the suggestion to use someone’s birthday ;) ****
>>
>> ** **
>>
>> *From:* James Simonsen [mailto:simonjam@google.com]
>> *Sent:* Monday, September 16, 2013 12:02 PM
>> *To:* public-web-perf@w3.org
>>
>> *Subject:* 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 ****
>>
>>  ** **
>>
>
>