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.
What this means
Daylight saving time advances or rewinds the local clock by an hour on fixed transition dates. On the spring transition the local hour (often 02:00–03:00) does not exist; on the autumn transition it occurs twice. A report that buckets events by local hour therefore shows a hole or an overlap.
The day of the change has 23 hours (spring) or 25 hours (autumn), which skews any per-day average that assumes 24 hours.
Why UTC helps
Storing and analyzing in UTC removes the discontinuity, because UTC has no DST. Convert to local time only for display, and annotate transition days so readers do not misread the missing or doubled hour as a data incident.
- Spring forward: one local hour is missing
- Fall back: one local hour repeats
- Transition days have 23 or 25 hours, not 24
- Analyze in UTC, convert for display
How it appears in analytics and logs
A missing or doubled hour on the exact DST changeover date is an artifact of local-time bucketing, not a tracking outage or a genuine traffic surge.
Diagnostic use case
Explain a one-hour gap or spike on DST transition days and decide whether to analyze in UTC to keep comparisons clean.
What WebmasterID can help detect
WebmasterID can present hourly data so DST-driven gaps and doubles are distinguishable from real changes in traffic.
Common mistakes
- Reading the DST hole as a tracking outage.
- Reading the doubled hour as a real spike.
- Averaging per-hour on a 23- or 25-hour day.
Privacy and accuracy notes
DST handling concerns timestamp bucketing only and involves no personal data. WebmasterID stores event time precisely so local-time artifacts can be reasoned about.
Related pages
- 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.
- 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.
- 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.
- Website Observability
Read hourly trends without time artifacts.
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.