All packsOffline Sync EngineSolve
offline sync clock skew local edits reverting
A wrong device clock makes your own edits disappear
A device with a slow clock loses every edit it makes to a value it just pulled from a fast-clocked device -- the user watches their own edit revert.
What goes wrong
Last-write-wins conflict resolution needs a way to compare "when" two writes happened, and if that comparison is based on each device's own physical clock without correction, a device whose clock is meaningfully behind another device's will lose every conflict, even for edits made after the fact from the user's perspective. The user edits a field on screen, it saves, and then a later sync pulls the other device's earlier-clock-but-higher-priority write back over it -- the edit visibly reverts with no error shown.
Why agents get it wrong
Using Date.now() as a write's timestamp is the obvious, simplest implementation of last-write-wins, and it works correctly on every device whose clock happens to be accurate -- which is nearly all of them, nearly all of the time, in casual testing. The failure mode requires an actual clock skew between two specific devices to reproduce, which most development and QA setups don't have.
What Offline Sync Engine pre-decides
The engine's observe() method folds in every remote physical timestamp it sees -- from pulled changes and from serverTimeMs on every sync response -- so a device's next locally minted timestamp is guaranteed to exceed everything it has ever observed, regardless of its own clock's accuracy. On top of that, the server outright rejects (400 clock_skew) any push whose physical time is more than 5 minutes ahead of server time, and the client re-stamps its entire outbox using server time and retries, rewriting its own local cells so it doesn't just correct future writes but stops rejecting legitimate past ones too.
Source: ARCHITECTURE.md 'Clock skew policy (decided)'