Timezones and Date Boundaries
Date: 2026-08-16
One report’s Monday is another’s Sunday night. It’s the least interesting cause of a discrepancy and the most common — which is why it’s the first thing to check and almost never the thing anyone checks first.
What it is
A date boundary is where a system decides one day ends and the next begins. Systems disagree because each has its own configured timezone, and events near midnight fall on different sides.
order placed 23:47 UTC, Sunday 15 August
analytics (Europe/London, BST = UTC+1) → 00:47 Monday 16th
warehouse (UTC) → 23:47 Sunday 15th
finance (Europe/London) → Monday 16th
ad platform (America/Los_Angeles) → 16:47 Sunday 15th
one order, three different dates
Nothing is broken. Four systems, four correct answers, no reconciliation.
Where the disagreements come from
- Different configured timezones across tools, usually set at creation and never revisited
- UTC storage, local display, or the reverse — and the conversion happening at different layers
- Ad platforms defaulting to their own timezone, frequently US-based regardless of your market
- The client’s timezone versus the server’s. An event timestamped by the browser carries the user’s local time
- Daylight saving. In the UK, clocks change twice a year, producing one 23-hour day and one 25-hour day. Any year-on-year comparison across those dates is comparing unequal periods
- Week start. Monday in the UK, Sunday in most US-built tools. A “week-on-week” comparison across two tools compares different weeks
Why it’s disproportionately the answer
Because the effect concentrates where you look most:
- Daily reports are worst affected — a full day’s boundary shift can move a meaningful share of orders
- Weekly and monthly boundaries shift the same way, and a month boundary lands on the busiest reporting cycle
- Campaign periods starting and ending at midnight in the wrong zone include or exclude a full evening
- Evening-heavy traffic — which retail is — puts more orders near the boundary than a business-hours pattern would
In plain terms: the closer a business is to a midnight-heavy traffic pattern, the more orders sit near the line, and the bigger the discrepancy from a one-hour offset.
Fixing it
- Pick one timezone for reporting and configure every system to it. For a UK business,
Europe/London— accepting that this means DST-affected days — or UTC, accepting that summer reports are offset by an hour from the working day - Store in UTC, convert at query time. The warehouse pattern, and the only one that lets you restate a report in a different zone later
- Write the timezone into every metric definition. It’s one of the seven fields — Metric Design
- Label it on dashboards. “Orders (Europe/London)” ends the conversation before it starts
- Align ad platforms to the same zone where they allow it, and note where they don’t
- Never compare across DST changes without checking. The last Sunday in March and the last in October are the dates to remember in the UK
The diagnostic habit
Check the timezone before investigating anything else. It’s first in the ordered rule in the symptom list and first in the reconciliation step of Guide - Auditing a Tracking Plan, for one reason: it’s the cheapest check and it resolves a large share of apparent discrepancies.
The test is quick: compare the same period at a monthly grain rather than daily. If the gap largely disappears, it’s a boundary problem — the orders are there, they’re just landing on different days. If it persists at monthly, it’s genuine tracking loss and worth pursuing — Tool Discrepancies.