Server-authoritative time and client timers
Calibrate a server-time anchor; redraw the deadline from elapsed time, not callback counts.
Predict first
Before you read: predict
A console badge stores a server deadline of 90000, an estimated server reading of 80000 at monotonic reading 5000, and initially shows ten seconds. Redraw callbacks occur at monotonic readings 6000 and 11000; between them the device wall clock moves forward by 40000. All timestamps are virtual milliseconds. Round positive remaining time upward; clamp expired values to zero.
At the second redraw, what whole seconds should the calibrated badge show?
The 30-second version
Estimate server time from a round trip, then store that estimate beside the current monotonic reading. At redraw, add monotonic elapsed time to the estimate and subtract from the server deadline. Round up positive seconds; clamp expired values. Callbacks trigger redraws, not elapsed-second counts. Device wall-clock edits do not change the stored pair.
Calibrate a server-time anchor; redraw the deadline from elapsed time, not callback counts.
How it works
Step 1 of 7
Analogy: A technician synchronizing a bench clock
The selected image shows a technician comparing a small clock with a large reference clock. Moving the small clock's hands corrects its reading at that instant; its own ticks then advance the reading between comparisons. Counting how often the technician looks up would measure visits, not elapsed time. A replacement clock needs another comparison before its reading can be related to the reference.
| Observed relation | Mechanism |
|---|---|
| Comparison with the reference face | Calibration against server time |
| Saved reading plus subsequent tick duration | Anchor plus monotonic elapsed time |
| Looking up after several ticks | Redrawing after a delayed callback |
| Replacing the small clock | Establishing a new time origin |
In real terms: retain a conversion between the reference and the advancing local clock. Limits: the picture has no message transit and cannot explain path asymmetry; the equations above supply that missing mechanism. Contrasting case: a clock whose hands move only when someone looks at it counts observations. Scheduling and debounce remain in the event-loop record and debounce/throttle.
Examples, run for real
Admin deadline badge: EXH-1970 → MR !2170
The deadline is 25000. These are synthetic inputs. The model executes the RFC equations; it does not send NTP packets. Redraws occur only when the fixture supplies them. RFC 5905
E1 sample offset=290 network=60
E1 redraw states=14,11,0
E1 decrement states=14,13,12
| Step | State/event | Observed model output |
|---|---|---|
| 3 | Four timestamps received | offset=290 network=60 |
| 4–5 | Monotonic redraws 1400, 4400, 18400 | 14,11,0 |
| 6 | Decrement initially rounded display once per redraw | 14,13,12 |
The repaired badge reaches its expired state despite skipped opportunities. The defective counter remains positive because it counts callbacks. This demonstrates a permitted delayed-callback trace; it does not claim browsers deliver that particular trace. Timer documentation supplies the reason such a count is unsafe. MDN timer delays
A separate ungraded Node run of timer-observation.mjs blocks its event loop and prints callback counts. It checks that the virtual premise is possible on this runtime, not that browsers share this cadence:
elapsed whole seconds 5 · interval callbacks 2 · counter would show 8 from 10, clock-based 5
Checkout hold and asymmetric paths
A checkout hold uses deadline 100000, server anchor 85000, monotonic anchor 7000 and redraw 12000. Changing device wall time after calibration leaves the computed display unchanged. A separate path simulation holds true clock offset at 400 and changes outbound/return delays, retaining server processing as a separate interval. MDN, RFC 5905
E2 wall adjustment ignored: before=10 after=10
E3 symmetric offset=400; asymmetric estimate=430; true offset=400
The asymmetry example prevents overclaiming: an estimate can be stable and still be biased. The server must apply its own acceptance policy; this lesson invents no grace window and does not treat a displayed positive number as receipt evidence. Authentication, transport replay and late-write policy require their own contracts. The executed artifact proves the arithmetic and displayed states under stated inputs, not production deadline accuracy.
Picture it

Try it
Answer first, then check. Nothing is saved.
Question 1 of 5
A hold-page exchange logs client-send 1000, server-receive 890, server-send 920, client-receive 1050, all virtual milliseconds. A network simulator records outbound transit 15 and return transit 5; neither clock changes.
What server-minus-client offset generated these observations?
Question 2 of 5
A hold renderer uses ceiling seconds and clamps at zero. Its anchor is {deadline:46000, server:40000, mono:1000}. It redraws at monotonic readings 6999, 7000, 7001, 8101.
Which four values appear?
Question 3 of 5
A reservation badge begins at twelve seconds and decrements once per callback. The fixture invokes it at elapsed seconds 1, 2, 10, with no intervening callbacks.
At the last callback, by how many seconds does that counter exceed the deadline-based display?
Question 4 of 5
A calibration exchange logs wall-clock timestamps: client-send 20000, server-receive 20440, server-send 20480, client-receive 20100. Monotonic readings are 7400 at send and 7500 at receipt. The hold deadline is 26000. All units are virtual milliseconds and clocks stay stable during the exchange. The next redraw calls render(anchor, performance.now()).
Which replacement anchor should be installed?
Question 5 of 5
A page saves {deadline:120000, server:100000, mono:9500}. After navigation, a response estimates server time 107400 at the new page's monotonic reading 900; the request began at monotonic 100. The screen immediately shows 22 seconds. The renderer uses ceiling seconds and clamps at zero.
Which update path explains this observed display?
Go deeper
Pro tip
Record clock domain and units alongside each diagnostic timestamp. This is a DOC tip derived from RFC 5905's four timestamps and MDN's time-origin distinction; it is not a timing benchmark or an answer to a particular assessment.
Sources
Fetched and saved on 2026-09-30 using the web reader. RFC 5905 §8 supports the offset and network-delay equations; MDN performance.now supports monotonic origins, wall adjustments and sleep caveats; MDN setTimeout supports delayed callbacks. Formula implementation is deliberately a small model, not the full clock-selection or discipline protocol.
Related lessons
Checked against the tools and docs as of 2026-09-30.