Der Sonntag hatte in der Schweiz eine zusätzliche Stunde. Das ist nicht nur beim Umstellen der Uhr wichtig, sondern auch beim Vergleich täglicher Besucherzahlen.
Am 25. Oktober 2026 wurden die Schweizer Uhren von 03:00 auf 02:00 zurückgestellt. Der lokale Kalendertag dauerte 25 verstrichene Stunden. Ein UTC-Bericht für dasselbe Datum deckte ein anderes Zeitfenster ab. Beide Definitionen können stimmen, ihre Summen müssen trotzdem nicht übereinstimmen.
Prüfen Sie deshalb vor einer Wachstumsinterpretation, was der Bericht mit einem Tag meint.
Ein Datum kann zwei verschiedene Zeitfenster bezeichnen
Das Datum 2026-10-25 ist noch kein vollständiger Zeitraum. Dazu gehören eine Zeitzone und Grenzen.
Für einen Geschäftstag in Europe/Zurich beginnt der Zeitraum um lokale Mitternacht und endet um die nächste lokale Mitternacht. Wandeln Sie beide Zeitpunkte in UTC um. Innerhalb dieses konkreten Intervalls ändert sich der Offset. Es dauert deshalb nicht 24 Stunden.
| Berichtsdefinition | UTC-Beginn, eingeschlossen | UTC-Ende, ausgeschlossen | Verstrichene Stunden |
|---|---|---|---|
| 25. Oktober in Europe/Zurich | 2026-10-24 22:00 | 2026-10-25 23:00 | 25 |
| 25. Oktober in UTC | 2026-10-25 00:00 | 2026-10-26 00:00 | 24 |
Ein hypothetisches Ereignis um 2026-10-24T22:30:00Z gehört in Zürich zum 25. Oktober, in UTC aber zum 24. Oktober. Das Ereignis hat sich nicht verändert. Die Berichtsgrenze schon.
Die Schweizer Umstellung bestätigt die METAS-Mitteilung. Die Tabelle ist ein Rechenbeispiel für Berichtsgrenzen, keine gemessene Kundenaktivität.
Zuerst die Grenzen bestimmen, dann die Dauer
Für einen lokalen Kalendertag werden die Mitternacht des gewählten Datums und die Mitternacht des Folgetags in derselben benannten Zeitzone erstellt. Erst nach der Umwandlung beider Zeitpunkte in UTC wird ihre Differenz als verstrichene Zeit berechnet. Ersetzen Sie die zweite Grenze nicht durch die erste plus 86.400 Sekunden.
Dieses Python-Beispiel verwendet zoneinfo und die auf dem Rechner verfügbaren IANA-Zeitzonendaten. Es benötigt Python ab Version 3.9 und installierte Zeitzonendaten. Fehlen diese, installieren Sie das offizielle Paket tzdata, statt einen festen UTC-Offset einzusetzen. Die Python-Dokumentation erklärt diese Abhängigkeit.
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()}")
Die Ausgabe lautet:
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
Die Subtraktion erfolgt bewusst nach der Umwandlung in UTC. Pythons Regeln für datetime-Subtraktion rechnen mit lokaler Uhrzeit, wenn zwei zeitzonenbewusste Datumsobjekte dasselbe tzinfo-Objekt verwenden. Das ist nicht die hier gezeigte Berechnung verstrichener Zeit.
Die beiden fold-Werte bezeichnen unterschiedliche Vorkommen von 02:30 in der wiederholten Stunde. Eine Beschriftung nur mit lokaler Uhrzeit kann sie nicht unterscheiden. Bewahren Sie den tatsächlichen Ereigniszeitpunkt auf und zeigen Sie bei Bedarf den Offset oder eine andere eindeutige Kennzeichnung.
Dies ist eine lokale Berechnung. Sie sendet keine Analytics-Anfragen, ändert keine Kontoeinstellungen und demonstriert keine Zeitzonenumschaltung in einem Produkt.
Kalendertag und rollierende 24 Stunden trennen
Gestern in Zürich und die letzten 24 Stunden beantworten unterschiedliche Fragen. Die erste Angabe folgt Kalendergrenzen einer benannten Region. Die zweite beschreibt eine verstrichene Dauer bis zu einem bestimmten Zeitpunkt.
Ein Bericht für den laufenden Tag ist ein weiterer Fall: Er kann unvollständig sein. Wer heute um 10:00 mit dem gesamten gestrigen Tag vergleicht, vergleicht auch ohne Zeitumstellung unterschiedliche Beobachtungsdauern.
Halten Sie bei einem Export oder Vergleich Zeitzone, Beginn, Ende und Gruppierungsregel fest. Eine sichtbare Beschriftung genügt nicht. Zeigt ein Diagramm lokale Stunden, prüfen Sie die Darstellung der wiederholten Stunde. 24 sichtbare Beschriftungen belegen nicht automatisch 24 verstrichene Stunden.
Berechnen Sie für einen Geschäftstag in einer anderen Region deren eigene Grenzen. Übertragen Sie weder Zürichs Offsets auf andere Märkte noch eine einstündige Umstellung als feste universelle Regel.
Mehr Zeit kann mehr Ereignisse ergeben, ohne höhere Rate
Ein hypothetisches System erfasse genau 10 Ereignisse je verstrichener Stunde. Ein 24-Stunden-Fenster enthält dann 240 Ereignisse, ein 25-Stunden-Fenster 250. Die Summe liegt ungefähr 4,17 Prozent höher, die stündliche Rate bleibt unverändert.
Das ist eine Rechnung, keine Vorhersage realer Besucherzahlen. Menschen besuchen eine Website nicht mit konstanter Rate. Wochentag, Kampagnen und Zielgruppenmix bleiben relevant. Eine Division durch die Stunden kann die Ereignisintensität erklären, macht zwei Tage aber nicht automatisch vergleichbar.
Auch sollte nicht jede Kennzahl auf Stunden normiert werden. Eindeutige Besucher sind kein additiver Ereigniszähler. Eine Conversion-Rate braucht eine klare berechtigte Grundgesamtheit und ein Beobachtungsfenster, nicht einfach eine zusätzliche Division durch die Tageslänge. Der Nenner kann die Aussage verändern, selbst wenn die Prozentzahl unkompliziert aussieht.
Zeigen Sie Summe und Beobachtungsdauer gemeinsam, wenn der Unterschied für die Entscheidung zählt. Trennen Sie hypothetische Beispiele sichtbar von Messwerten.
Die Grenze zum Bestandteil des Vergleichs machen
Bei einer neuen Abfrage ist ein halboffenes Intervall eine nützliche Konvention: Ereignisse am Beginn einschliessen, Ereignisse an der nächsten Grenze ausschliessen. Also timestamp >= start AND timestamp < end. Benachbarte Intervalle teilen so eine Grenze, ohne ein dort liegendes Ereignis doppelt zu zählen.
Ändern Sie den Vertrag eines bestehenden Berichts nicht stillschweigend auf diese Konvention. Prüfen Sie beim Abgleich von Exporten die tatsächliche Einbeziehung des Endzeitpunkts, die Zeitstempelpräzision, Filter, Verarbeitungsstatus und Zähleinheit. Derselbe Datumstext belegt keine Übereinstimmung dieser Regeln.
Ein praktischer Testsatz enthält einen normalen lokalen Tag, die Frühjahrs- und Herbstumstellung, ein Ereignis genau an jeder Grenze und beide Vorkommen einer wiederholten Uhrzeit. Halten Sie die erwarteten UTC-Zeitpunkte neben dem Test fest.
Das Ziel ist nicht, jedes Dashboard auf eine einzige Zeitzone zu zwingen. UTC kann für den Betrieb richtig sein, ein lokaler Kalendertag für die Geschäftsfrage. Benennen Sie die verwendete Grundlage und vergleichen Sie passende Fenster, bevor Sie eine Differenz als Wachstum interpretieren.
