[Webkit-unassigned] [Bug 225610] performance.now() does not tick during system sleep

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=225610

--- Comment #2 from Jonathan Mayer <webkit-bugzilla at mayerware.com> ---
(In reply to Alexey Proskuryakov from comment #1)
> Thank you for the super detailed report!
> 
> Seeing that most browsers are not compliant with this spec change, I'm wondering what the rationale for changing established behavior is.

Here's the W3C spec discussion: https://github.com/w3c/hr-time/issues/65

A few reasons for consideration:
* Consistency with API user expectations, especially since the widely used Date.now() ticks during system sleep.
* Consistency across browsers and platforms.
* Provides valuable semantics for performance.timeOrigin + performance.now(). Those timestamps will be, within a browsing session: 1) monotonic, 2) comparable across documents, 3) unaffected by major or non-monotonic adjustments to the system clock, and 4) approximately equal to the current time, assuming the system clock was accurate at browser startup. The reason I started digging into this issue is that my academic research group is relying on those very semantics for a project. :)

> Comparing a monotonic clock to system clock will break once a year in most locations anyway, as the system clock will go backwards.

If you mean leap seconds, I think that's OK. There's no guarantee of how close the monotonic clock and the system clock will be at any particular moment, since the system clock can change at any time. What a browser can guarantee is: 1) the monotonic clock value is approximately equal to the  value the system clock would have if it wasn't subject to a major or non-monotonic adjustment after browser startup, and 2) the only other causes of divergence between the monotonic clock and the system clock are a) underlying clock implementation differences (unlikely now, with convergence on invariant TSC for x86 timing and Generic Timers for ARM timing), and b) leap second subtraction or smearing on the system clock (which an API user could account for if necessary by implementing their own leap second subtraction or smearing).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210511/e2099bb8/attachment-0001.htm>