Compares three clocks: this browser's raw local clock, this browser synced directly to PTB over WebSocket (WST), and this browser's view of the backend's clock (which is itself NTP-synced to PTB).
Keep the interval reasonable (60s+) — PTB doesn't publish a rate limit for this service, so don't hammer it while testing.
Date.now(), no correction.Each row is one moment in time, read off all three clocks. The delta columns show how far the PTB- and backend-corrected times are from the browser's raw local clock at that instant.
| Local (ISO) | PTB-corrected | Backend-corrected | Δ PTB vs local | Δ Backend vs local |
|---|
Accumulated across every sync this session (page reload resets it). This is the data that actually answers "how much does relaying through our server + NTP cost, versus syncing straight to PTB" — a single reading doesn't; the spread across many readings does.
| Metric | PTB direct | Backend (NTP-relayed) |
|---|---|---|
| Successful / failed syncs | — | — |
| Offset: mean (ms) | — | — |
| Offset: std dev (ms) | — | — |
| Offset: min / max (ms) | — | — |
| Delay: mean (ms) | — | — |
| Delay: min / max (ms) | — | — |
Discrepancy = (backend offset − PTB offset), from paired syncs run at the same moment. This is the direct cost of relaying through your server instead of going straight to PTB.
| Paired samples | — |
| Mean (ms) | — |
| Std dev (ms) | — |
| Min / max (ms) | — |