Never Trust the Device Clock

Systems & Architecture · data integrity, tables, real-time

Updated 2026-08-04

Treat the clock on a phone or laptop as unreliable. Devices drift, users set them manually, and servers in different places disagree by enough to matter, so a timestamp is not an ordering.
Stamp events on the server and display them in the viewer's timezone. Recording the moment on the device produces items that appear to happen before the action that caused them.
Sort by the sequence the system assigns, not by the displayed time. Two records showing the same minute still have a definite order, and the interface should use it.
Watch for the symptoms of clock skew, because they read as bugs:

Compute relative times from an offset to the server rather than from the device clock. Measure the difference once on load, then apply it, so 2 minutes ago stays true on a machine set to next year.
Clamp what cannot be real. A future timestamp on a past event should display as the present rather than as a date nobody can explain.
Show the absolute time alongside the relative one wherever the exact moment matters. Audit trails, receipts, and incident timelines are read to establish order, so 3 hours ago on its own is not enough.
Say which timezone a stored time is in when people in different places read the same record. Ambiguous times cause missed meetings and disputed deadlines.

Displayed time is a story about ordering, and the device is the worst available narrator.