Technical
Hit timestamp
Also called event time.
Hit timestamp is the date and time recorded on an incoming event, normally stored in UTC and displayed in the property's reporting zone. Depending on the tool it is either the browser's claimed time or the moment the collector received the request.
How it is measured
Two clocks exist: the client's (`Date.now()` in the payload, which can be off by minutes or years) and the server's receive time. Compare them on the same event. A skew over a few seconds suggests a bad device clock, and a client time in 1970 is junk.
Store epoch milliseconds or ISO 8601 with a `Z`. Reports then convert to the property zone, so a hit at 23:40 UTC on Monday is Tuesday 07:40 in Singapore.
Worked example
A support site's collector logs one hit with client time 2026-10-01T06:12:09Z and server time 06:12:11Z, a lag of two seconds. Another hit, from an unattended lobby kiosk, claims 2026-09-18 while the server says 2026-10-01. Its battery clock reset.
The collector now trusts the server time whenever skew passes 300 seconds. Eleven hits a day stop landing in the wrong day's bucket.
How it differs
A hit timestamp is a point in time. A timezone is the rule that turns that point into a calendar day. One hit with one timestamp falls on different days for two properties set to different zones.
Common errors
Trusting the device clock. Storing local time with no offset. Parsing a bare date-time as local on one machine and UTC on another. Ignoring daylight saving, which gives you a 23-hour day. Mixing event time with receive time for hits queued offline.
In practice
Store UTC and convert only at read time. Record both client and server times and alert when skew exceeds a minute. On the weekend daylight saving flips, look at the hourly chart for a gap or a doubled hour.