W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2011

Re: Timing API issues with wall-clock time

From: James Simonsen <simonjam@chromium.org>
Date: Tue, 12 Apr 2011 12:57:15 -0700
Message-ID: <BANLkTi=sHohJc-oYSp5MbRa+Uph5r9bAUA@mail.gmail.com>
To: public-web-perf@w3.org
On Tue, Apr 12, 2011 at 2:26 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> I just noticed that the navigation timing API is defined in terms of
> wall-clock epoch times.  Unfortunately, such times on modern computer system
> have an unpleasant property: they are not monotonically increasing at the
> rate time actually passes at.  In particular, NTP adjustments, leap seconds,
> user configuration changes, and so forth can cause the epoch time reported
> by the system to go backwards, go forwards to fast or go forwards too
> slowly.

We're already seeing complaints about this with Chrome. We'd be in favor of
somehow moving to monotonically increasing time.

One of the original goals was to be able to compare easily with Date
objects. Instead of that, perhaps we should expose a monotonic clock to the
page? Navigation Timing could then be switched to use the monotonic clock
instead of the wall clock.

There might be other benefits to having a monotonic clock on the page, like
for use with animation.

Received on Tuesday, 12 April 2011 19:57:41 UTC

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