Server time vs client time
An event's timestamp can come from the client (the browser's clock at the moment of the action) or the server (when the collector received the hit). The two differ because of clock skew, network delay, and offline buffering, and the choice affects ordering, attribution windows, and which day an event lands on. This page contrasts the two clocks.
What this means
Client-side timestamps reflect the device clock when the event occurred, which can be wrong if the user's clock is misconfigured. Server-side timestamps reflect when the collection endpoint received the request, which is consistent but lags the real action by network and buffering time.
GA4's Measurement Protocol lets callers supply a `timestamp_micros`; without it the server stamps arrival time, and large client/server gaps can be rejected or reassigned.
Why it matters
If a report uses client time, a single device with a wrong clock can scatter events across days. If it uses server time, offline or queued hits collapse onto their arrival moment rather than when they happened. Knowing which clock a metric uses prevents misreading ordering and daily totals.
- Client time: accurate to the action, vulnerable to bad clocks
- Server time: consistent, but lags by network and buffering
- Measurement Protocol can supply an explicit timestamp
How it appears in analytics and logs
Events that arrive out of sequence or on the wrong day often reflect client-vs-server timestamp differences — a wrong client clock or a delayed, buffered hit, not corrupted data.
Diagnostic use case
Decide which timestamp a report uses and account for skew when events appear out of order or land on an unexpected day.
What WebmasterID can help detect
WebmasterID applies a consistent server-side timestamp, so event ordering does not depend on the accuracy of each visitor's device clock.
Common mistakes
- Assuming all tools use the same clock for timestamps.
- Trusting client timestamps from devices with wrong clocks.
- Ignoring buffering delay when reading event order.
Privacy and accuracy notes
Timestamps are not personal data, though a precise client clock can be a fingerprinting input; collectors typically normalize to server time. WebmasterID timestamps server-side for consistency.
Related pages
- Late-arriving and offline hits
Not every hit arrives when it happens. A device offline queues events and sends them on reconnect; processing pipelines add delay; and tools backfill recent data. The effect is that today's and yesterday's numbers are provisional and keep rising as late hits land. This page explains why fresh reports change under you and how to read them.
- Daylight-saving time anomalies
When a region enters or leaves daylight saving time, one local hour vanishes (spring forward) or repeats (fall back). Reports bucketed by local wall-clock time then show a missing hour or a doubled hour, and the affected day has 23 or 25 hours. This page explains the artifact and why UTC-based analysis avoids it.
- Time-zone mismatches in reporting
Every analytics property reports against a configured time zone, and it decides which calendar day each hit belongs to. A wrong zone shifts your daily curve; two tools on different zones never match day-to-day; and daylight-saving changes create a short or doubled hour. This page explains how the reporting time zone shapes data and the artefacts to expect.
- Website Observability
Consistent server-side event timing.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.