A mobile client stamps each event with its own clock and the server stores that timestamp. Why does this break reporting and de-duplication, and what should the server record instead?

Why the device clock is not a fact

A server clock is disciplined by NTP and monitored. A device clock is a user-editable setting. It drifts while the device is offline, it jumps when the user crosses a timezone or fixes the date manually, and on some devices it is set deliberately — moving the clock forward is the oldest way to skip a timer in a game.

The consequence is not a rounding error. Events arrive with timestamps in the future, in the past, or in an order that never happened, and every aggregate computed from them inherits the damage.

What actually breaks

• Daily counts move after the fact. An event stamped two days ago arrives today and lands in a closed reporting period, so yesterday's number changes overnight and nobody trusts the dashboard.
• Ordering across devices is meaningless. Two devices disagree by minutes, so "which edit came last" cannot be answered from their timestamps.
• De-duplication fails. A retry after a reconnect carries a new timestamp, so a timestamp-keyed dedup lets the duplicate through, and the user is charged twice or the step count doubles.

What the server should record

Three values instead of one, each with a job:

1. Client event time, kept as reported, because it is the only evidence of when the user acted.
2. Server receive time, which is authoritative for billing, reporting periods and anything a regulator or a finance team reads.
3. A per-device monotonic sequence number plus a boot or install id, which gives correct ordering within a device without trusting its clock at all.

De-duplicate on a client-generated idempotency key, not on a timestamp. The key is created when the event is created and survives every retry, which is exactly the property a clock lacks.

Skew is also measurable: record the client's clock at send alongside the server's clock at receive, and you have a per-device offset you can correct with, and an alert when a fleet's offsets shift.

The rule to carry

Client time for ordering within one device. Server time for ordering across devices and for anything financial. Then decide the lateness window explicitly — commonly 24 to 72 hours for mobile telemetry — and state what happens to events arriving after it, because "we drop them silently" is a decision whether or not anyone made it.

When this is the wrong answer

If events never leave the device, the device clock is the only clock there is and this machinery buys nothing: a local reminder, an on-device streak counter, a session timer. The complexity is justified when events are aggregated across devices or across users, which is the moment two clocks must be reconciled into one story.