- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 12 Apr 2011 02:26:27 -0700
- To: public-web-perf@w3.org
Dear web perf working group, 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. In terms of the navigation timing API what this means is that some of the durations can be negative (or just completely incorrect). Worse yet, there is no reasonable way to tell when the latter has happened. I think it would be (have been, if people are not willing to switch at this point) to define navigation timing in terms of an epoch start time for the navigation and then durations (in whatever time units) from the navigation start time for the other times. That would allow implementations to directly measure elapsed time from navigation start instead of sampling a wall-clock at two points in time and hoping that the difference between the reported values actually corresponds to how much time has elapsed. -Boris
Received on Tuesday, 12 April 2011 09:26:58 UTC