Untrusted Client Timestamp

A finance team asks why yesterday's revenue changed overnight. The answer is that a phone was in flight, its events were buffered, and they arrived this morning carrying yesterday's client timestamps, landing in a period that had already been reported.

A device clock is a setting, not a measurement. It drifts while offline, jumps when the user crosses a timezone or corrects the date, and is sometimes moved deliberately — advancing the clock is the oldest way to skip a cooldown timer.

Why it matters

Three things are usually built on the assumption that the client timestamp is true, and all three break: reporting periods that must be stable once closed, ordering across devices, and de-duplication. None of them fail loudly. The dashboard simply stops matching, and trust in it goes before anyone finds the cause.

Implementation patterns

• Store three values, not one. Client event time as reported, server receive time as authoritative for anything financial or regulatory, and a per-device monotonic sequence number with a boot or install id for ordering within a device.
• De-duplicate on a client-generated idempotency key created when the event is created, so it survives every retry. A timestamp does not.
• Measure skew by recording the client clock at send next to the server clock at receive. That gives a per-device offset to correct with and a fleet-level alert when offsets shift after an operating system release.
• State the lateness window — commonly 24 to 72 hours for mobile telemetry — and decide explicitly what happens to events arriving after it, because silent dropping is a decision either way.
• Never accept client time for anything security-relevant: token expiry, rate-limit windows, promotional eligibility.

Industry example

Every analytics pipeline that distinguishes event time from ingest time exists because of this problem, and the watermark machinery in stream processors — deciding how long to wait for late data before closing a window — is the industry's standard answer. Mobile-heavy products in production routinely see a small but persistent share of devices reporting clocks hours or days out, which is why mature pipelines keep both timestamps and let the analyst choose rather than resolving it at ingest.

Failure scenarios

• Retroactive reporting changes, where a closed period moves and nobody can explain it.
• Duplicate charges or doubled counters, because dedup keyed on a timestamp let a retry through.
• Events from the future, which sort to the top of every "latest" query and dominate dashboards until someone filters them.
• Cheating in games and loyalty programmes, where the device clock controls a cooldown.
• Sync conflicts resolved backwards, when last-write-wins uses the client clock and the wrong write wins.

Trade-offs

Keeping two timestamps costs storage and forces every query to state which one it means, which is a real burden on analysts and a common source of inconsistent reports. Resolving to a single time at ingest is simpler and throws away the evidence of when the user acted. Keep both and name them clearly; the cost of the ambiguity is smaller than the cost of the loss.

When not to use it

If events never leave the device, the device clock is the only clock there is. A local reminder, an on-device streak, a session timer: adding server time to these adds nothing. The machinery becomes necessary at the moment events from more than one device are aggregated into a single story.

Interview question

Q: Your mobile app buffers events offline and uploads them on reconnect. Finance reports that revenue figures for closed months keep moving. Walk me through the diagnosis and the fix, including what you would tell finance about the numbers they have already published.

What a strong answer covers: event time versus ingest time as the root cause · separating the two timestamps and defining which one reporting uses · the lateness window and a restatement policy · idempotency keys for dedup · measuring per-device skew · and the organisational half, which is agreeing with finance that reports are computed on receive time so they are stable, with event time available for product analysis.

Quick check

Quiz: Why is de-duplicating on a timestamp unsafe? A retry after a reconnect carries a fresh timestamp, so the duplicate does not match and is accepted.

Flashcard: Which clock is authoritative for billing? — The server's receive time; the client's is evidence of when the user acted and nothing more.