Should time origin be defined in terms of a monotonic clock?

[bzbarsky]

The way things are defined right now, it's not clear whether "time origin" is recorded via wall clock or a monotonic clock.

If it's via wall clock, then you can end up in a situation like this in a web page:

var now = performance.now();
var blob = new Blob(["postMessage(performance.now())"]);
var w = new Worker(URL.createObjectURL(blob));
w.onmessage = function (e) {
  alert(performance.translateTime(e.data, w) - now); // alerts a negative number
}

which seems suboptimal. Seems to me like the same monotonic clock used for performance.now() in general should be used for recording all time origins.

[toddreifsteck]

I was just walking scenarios with @DLehenbauer on this today before I saw your post. :-) My initial thinking was that this is ok, but I frowned when I hit the same conclusion and declared we would solve it later. Perhaps later is now.

Per that logic, wouldn't all contexts associated with a UA need a single cross-context "time origin" to allow for things such as a Push Service Worker starting a Window context?

[bzbarsky]

You don't necessarily need a single cross-context time origin. What you need is that any time you have two things that might use separate nonotonic clocks you do the following:

1. Ensure those clocks run at the same rate (this might be hard!).
2. Ensure that at some point you read both clocks "at the same time" (or close to it) and store the offset between them, so you can convert back and forth.

I really don't have good answers here so far, especially because I don't know how easy item #1 is across all architectures...

[bzbarsky]

Oh, and the reason I filed the issue is that the initial implementation of translateTime in Gecko in fact used wall-clock time origins, even though we have a perfectly good monotonic clock that's visible across all the relevant stuff at the moment.

[igrigorik]

@bzbarsky slight tangent, but didn't we say that negative numbers are possible and OK? For example, a message from a shared worker that was already running will result in a negative timestamp; same thing in any case where parent process (e.g. nested workers, iframes) sends a message to a child..

[bzbarsky]

Sure. Negative numbers are totally possible here.

[igrigorik]

As one option, we could add a note under https://w3c.github.io/hr-time/#monotonic-clock that recommends that the monotonic clocks for each origin are bootstrapped from a global monotonic clock, if available? I think that's a good best practice for where such thing is available.. I'm just not not sure we can make it a MUST due to platform gotchas, etc?

[toddreifsteck]

@igrigorik @bzbarsky I generally agree with the note that Ilya is thinking of adding.

Boris, was your thinking that this should be required by the spec or is a SHOULD sufficient?

[bzbarsky]

I don't know. It seems to me that in general our monotonic clock abstraction is super-leaky and doesn't really promise very much in the way of monotonicity except very locally. (This is the super-leaky part.)

[igrigorik]

nods... by design, right?

As it stands, we guarantee that you get monotonic timestamps within the same time-origin, and in #29 we're making that stronger by introducing the concept of a global monotonic clock (which, btw, also covers what we're discussing here). With that in mind, I suggest we close this issue with no action, and continue in #29?

[bzbarsky]

That seems reasonable.

[igrigorik]

👍 closing.