[webrtc-pc] timestamp definition in terms of performance.timeOrigin is off when the machine goes to sleep (#3123)

fippo has just created a new issue for https://github.com/w3c/webrtc-pc:

== timestamp definition in terms of performance.timeOrigin is off when the machine goes to sleep ==
spun off from https://github.com/w3c/webrtc-stats/issues/295

I have seen getStats timestamps which where off by hours. This happens on Linux and Mac if I interpret the table in https://github.com/w3c/hr-time/issues/115 correctly.

This snippet:
```
(async () => {
    const pc = new RTCPeerConnection();
    pc.createDataChannel('probe');                     // ensure stats get produced
    await pc.setLocalDescription(await pc.createOffer());

    const report = await pc.getStats();                // first getStats -> patched build latches HERE
    let s = null;
    for (const v of report.values()) if (v.type === 'peer-connection') { s = v; break; }
    if (!s) { console.error('no peer-connection stat'); pc.close(); return; }

    const wall = Date.now();
    const perf = performance.timeOrigin + performance.now();
    const skew = (wall - s.timestamp) / 1000;

    console.table({
      'stat.timestamp':            s.timestamp,
      'Date.now()':                wall,
      'timeOrigin+performance.now': perf,
      'Date.now() - stat (s)':     skew.toFixed(1),
    });
    console.log(skew > 5
      ? `⚠️   stat lags wall clock by ${skew.toFixed(1)}s  (stock Chromium)`
      : `✅  stat tracks wall clock (${skew.toFixed(1)}s)  (patched)`);
  })();
```
results in this after a 3+ minute sleep:
```
(index)
Value
stat.timestamp 1784128087348.651
Date.now() 1784128304692
timeOrigin+performance.now 1784128087348.8
Date.now() - stat (s) '217.3'
Object
VM38:21 ⚠️   stat lags wall clock by 217.3s  (stock Chromium)
```
same behavior in Firefox. The stats timestamp is minutes behind.

This only affects cases where the machine goes to sleep while the page is open and it does *not* affect deltas.
Tooling *can* work around this by estimating the clock skew and adjusting accordingly but so can the specification?

From what I can see we have three places in webrtc-pc that use DOMHighResTimestamp (including the stats) and three more in insertable streams.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/3123 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 15 July 2026 15:22:49 UTC