Sunday had an extra hour in Switzerland. That matters when you compare daily traffic, not just when you change a clock.
On 25 October 2026, Swiss clocks moved from 03:00 back to 02:00. The local calendar day lasted 25 elapsed hours. A report for that date in UTC covered a different window. Both can be valid, yet their totals need not match.
Before calling a daily increase growth, check what the word “day” means in the report.
One date can describe two different windows
The date 2026-10-25 is not a complete time range. It needs a time zone and boundaries.
For a Europe/Zurich business day, start at local midnight and end at the next local midnight. Convert those two instants to UTC. The offset changes inside this particular interval, so its duration is not 24 hours.
| Report definition | Start in UTC, included | End in UTC, excluded | Elapsed hours |
|---|---|---|---|
| 25 October in Europe/Zurich | 2026-10-24 22:00 | 2026-10-25 23:00 | 25 |
| 25 October in UTC | 2026-10-25 00:00 | 2026-10-26 00:00 | 24 |
A hypothetical event at 2026-10-24T22:30:00Z belongs to 25 October in Zurich and 24 October in UTC. Nothing about the event changed. The reporting boundary did.
The Swiss change is confirmed in the METAS announcement. The table is a worked example of reporting boundaries, not measured customer traffic.
Calculate the boundaries before the duration
For a local calendar day, construct midnight on the chosen date and midnight on the following date in the same named time zone. Convert both to UTC, then subtract them to measure elapsed time. Do not replace the second boundary with the first plus 86,400 seconds.
This Python example uses zoneinfo and the IANA time zone data available on the machine. It needs Python 3.9 or newer and installed time zone data. If that data is unavailable, install the first-party tzdata package rather than substituting a fixed UTC offset. The Python documentation describes that dependency.
from datetime import date, datetime, time, timedelta, timezone
from zoneinfo import ZoneInfo
zone = ZoneInfo("Europe/Zurich")
utc = timezone.utc
for day in (date(2026, 3, 29), date(2026, 10, 24), date(2026, 10, 25)):
start = datetime.combine(day, time.min, tzinfo=zone)
end = datetime.combine(day + timedelta(days=1), time.min, tzinfo=zone)
start_utc = start.astimezone(utc)
end_utc = end.astimezone(utc)
hours = (end_utc - start_utc).total_seconds() / 3600
print(f"{day}: {hours:g}h | {start_utc.isoformat()} to {end_utc.isoformat()}")
for fold in (0, 1):
local = datetime(2026, 10, 25, 2, 30, tzinfo=zone, fold=fold)
print(f"02:30 fold={fold}: {local.astimezone(utc).isoformat()}")
The output is:
2026-03-29: 23h | 2026-03-28T23:00:00+00:00 to 2026-03-29T22:00:00+00:00
2026-10-24: 24h | 2026-10-23T22:00:00+00:00 to 2026-10-24T22:00:00+00:00
2026-10-25: 25h | 2026-10-24T22:00:00+00:00 to 2026-10-25T23:00:00+00:00
02:30 fold=0: 2026-10-25T00:30:00+00:00
02:30 fold=1: 2026-10-25T01:30:00+00:00
The subtraction is deliberately done after conversion to UTC. Python’s datetime subtraction rules use wall-time arithmetic when two aware datetimes share the same tzinfo object. That is not the elapsed-time calculation shown here.
The two fold values identify different occurrences of 02:30 during the repeated hour. A label containing only the local clock time cannot distinguish them. Preserve the event’s actual instant and show an offset or another unambiguous identifier where repeated local labels matter.
This is a local calculation. It makes no analytics requests, changes no account settings, and does not demonstrate a timezone switch in a product.
Keep a calendar day separate from a rolling 24 hours
“Yesterday in Zurich” and “the last 24 hours” answer different questions. The first follows calendar boundaries in a named region. The second is an elapsed-duration window ending at an instant.
A current-day report is another case: it may be partial. Comparing today at 10:00 with all of yesterday adds an exposure difference even when there is no clock change.
Keep the time zone, start, end and grouping convention with an export or comparison. A display label is not enough. If a chart shows local hours, inspect how it represents the repeated hour instead of assuming that 24 visible labels mean 24 elapsed hours.
For a business-day analysis in another region, calculate that region’s boundaries. Do not carry Zurich’s offsets into another market or hard-code a one-hour change as a universal rule.
More time can produce more events without a higher rate
Suppose a hypothetical system records exactly 10 events per elapsed hour. A 24-hour window contains 240 events; a 25-hour window contains 250. The total is about 4.17 percent higher, while the hourly rate is unchanged.
That is arithmetic, not a forecast of real traffic. People do not visit at a constant rate, and weekday, campaign and audience mix still matter. Dividing by hours can help investigate event intensity; it does not automatically make two days comparable.
Nor should every metric be normalized by hours. Unique visitors are not an additive event counter. A conversion rate needs a clearly defined eligible population and observation window, not just an extra division by the day’s length. The denominator can change the story even when the displayed percentage looks straightforward.
Report both the total and the exposure when the distinction affects the decision. Keep hypothetical examples visibly separate from measured results.
Make the boundary part of the comparison
For a new query, a half-open interval is a useful convention: include events at the start and exclude events at the next boundary. In other words, timestamp >= start AND timestamp < end. Adjacent intervals then share a boundary without counting an event at that boundary twice.
Do not silently change an existing report’s contract to match this convention. When reconciling exports, check its actual end-time inclusivity, timestamp precision, filters, processing status and counting unit. The same date text does not establish that those rules agree.
A practical test set includes an ordinary local day, the spring transition, the autumn transition, an event exactly on each boundary, and both occurrences of a repeated local time. Keep the expected UTC instants beside the test.
The aim is not to force every dashboard onto one time zone. UTC can be the right operational basis; a local calendar day can be the right business basis. Name the one you use, and compare matching windows before interpreting the difference as growth.
