W3C home > Mailing lists > Public > public-web-perf@w3.org > September 2013

Re: [HighResTime] Web Worker support

From: James Robinson <jamesr@google.com>
Date: Wed, 11 Sep 2013 18:37:36 -0700
Message-ID: <CAD73mdK4pTcMCPrS6cqyyRYG4kJqcY6KM2Qx4CLY_mCLCpC4rA@mail.gmail.com>
To: Jatinder Mann <jmann@microsoft.com>
Cc: "benvanik@google.com" <benvanik@google.com>, "James Simonsen (simonjam@google.com)" <simonjam@google.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
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
Received on Thursday, 12 September 2013 01:38:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:21 UTC