Technical
Timezone
Also called reporting TZ.
Timezone is the zone a report uses to cut timestamps into calendar days, hours, and today. The same hit lands on different days in different zones.
How it is measured
Reports convert stored UTC times to the property's zone, ideally by an IANA name such as `Asia/Singapore` or `America/New_York`. That name carries daylight-saving rules, while a bare offset like +08:00 does not. Check by sending a hit at 23:30 UTC and seeing which day it lands in.
Find the zone setting in the dashboard and compare it with the zone of the people reading the report and of any other report you compare it to.
Worked example
A Singapore store runs a flash sale from 00:00 to 03:00 on Saturday local time. Its dashboard is set to UTC, so those three hours fall on Friday 16:00 to 19:00, and the Saturday total looks 41% below the cash register. Switching to `Asia/Singapore` moves the 1,180 orders onto Saturday.
Its ad platform is set to US Pacific, so daily cost rows still cut at a different hour from revenue, and day-level return keeps wobbling.
How it differs
A timezone assigns days to timestamps. A hit timestamp is the stored moment itself. Changing the zone moves hits between days but never changes when they happened.
Common errors
Using a fixed offset instead of an IANA name. Changing the zone mid-year and comparing old reports. Reading UTC logs against local dashboards. Forgetting that daylight saving makes 23-hour and 25-hour days. Setting different zones across tools. Treating a day as always 24 hours.
In practice
Pick one zone for the business and set it everywhere. Write down the date you change it. Compare tools only after aligning their zones.