Wenn 02:30 zweimal vorkommt: KI-Agenten bei der Zeitumstellung prüfen

Weshalb 02:30 Uhr an diesem Tag mehrdeutig ist

Das Eidgenössische Institut für Metrologie METAS bestätigt für den 25. Oktober 2026: Um 03:00 Uhr endet die Sommerzeit, die Uhren werden auf 02:00 Uhr zurückgestellt. Die Stunde zwischen 02:00 und 03:00 läuft damit zweimal ab.

Für 02:30 Uhr entstehen zwei gültige Möglichkeiten:

Die beiden Termine sehen auf einer Uhr gleich aus, liegen aber eine Stunde auseinander. Das Problem verschwindet nicht dadurch, dass im Auftrag «Schweizer Zeit» oder Europe/Zurich steht. Die Zeitzone liefert beide Möglichkeiten. Erst der UTC-Offset, eine UTC-Zeit oder eine andere eindeutige Zuordnung legt den Zeitpunkt fest.

In Software heisst diese wiederholte Stunde «fold». PEP 495 führte dafür ein Merkmal ein, das zwischen dem früheren und dem späteren Vorkommen derselben lokalen Uhrzeit unterscheidet. Die Python-Dokumentation zu zoneinfo zeigt dasselbe Verhalten für Zeitzonen aus der IANA-Datenbank.

Ein kurzer Test für einen KI-Agenten

Das folgende Szenario ist vollständig synthetisch. Es ist kein Kundennachweis und kein aktueller AgentBrain-Leistungstest.

Ein Betrieb lässt Wartungstermine aus E-Mails erfassen. Der Testauftrag lautet:

Trage den Wartungstermin am 25. Oktober 2026 um 02:30 Uhr für den Standort Zürich ein und bereite die Bestätigung vor.

Die Eingabe enthält Datum, lokale Uhrzeit und Ort. Trotzdem fehlt die entscheidende Angabe: Ist das erste 02:30 Uhr während der Sommerzeit oder das zweite 02:30 Uhr während der Normalzeit gemeint?

Ein prüfbares Ergebnis sollte die Mehrdeutigkeit sichtbar machen. Zum Beispiel:

Der Zeitpunkt ist nicht eindeutig. Am 25. Oktober 2026 kommt 02:30 Uhr in Zürich zweimal vor: einmal mit UTC+02:00 und einmal mit UTC+01:00. Welcher der beiden Termine ist gemeint?

Der Agent sollte bis zur Klärung weder einen Kalendereintrag erzeugen noch eine Bestätigung zum Versand freigeben. Eine sprachlich saubere Bestätigung mit dem falschen Zeitpunkt wäre hier kein Teilerfolg. Sie wäre eine falsche Aktion.

Welche Angaben einen Termin eindeutig machen

Für einen einzelnen Zeitpunkt braucht der Ablauf mehr als eine freundlich formulierte Datumszeile. Halten Sie mindestens diese Angaben fest:

1. Lokales Datum und lokale Uhrzeit: etwa 25.10.2026, 02:30 Uhr.
2. Zeitzone: etwa Europe/Zurich, nicht nur eine Abkürzung wie CET oder «Schweizer Zeit».
3. UTC-Offset oder UTC-Zeit: in diesem Fall entweder +02:00 beziehungsweise 00:30 UTC oder +01:00 beziehungsweise 01:30 UTC.
4. Quelle der Zeitangabe: E-Mail, Buchungssystem oder bestätigte Rückfrage.
5. Erlaubte Aktion: nur Entwurf, Kalendereintrag oder externer Versand. Diese Rechte sind getrennte Entscheidungen.

Speichern Sie bei einem festen Ereignis den eindeutigen Zeitpunkt und die zugehörige Zeitzone. Die Zeitzone bleibt wichtig, damit der Termin später korrekt in lokaler Zeit angezeigt werden kann. Für wiederkehrende Termine gelten andere Regeln: «jeden Sonntag um 02:30 Uhr» beschreibt eine lokale Regel und braucht eine ausdrückliche Festlegung für fehlende oder doppelte Uhrzeiten.

Vier Gegenproben machen aus dem Beispiel einen Test

Ein einzelner schwieriger Auftrag reicht nicht. Prüfen Sie auch Eingaben, bei denen keine Rückfrage nötig ist und solche, die aus einem anderen Grund gestoppt werden müssen.

Ergänzen Sie einen Durchlauf nach einem Neustart oder Systemwechsel. Prüfen Sie dabei, ob Zeitzone und Offset erhalten bleiben. Ein Textprotokoll allein genügt nicht: Vergleichen Sie den gespeicherten Zeitpunkt oder den vorbereiteten Kalendereintrag mit dem erwarteten UTC-Wert.

Was dieser Test zeigt und was nicht

Der Test zeigt, ob ein bestimmter Ablauf eine bekannte zeitliche Mehrdeutigkeit erkennt und wie er darauf reagiert. Er beweist nicht, dass alle Terminarten, Zeitzonen oder Kalendersysteme korrekt behandelt werden. Frühere und künftige Änderungen an Zeitzonenregeln kommen hinzu. Die IANA Time Zone Database wird deshalb laufend aktualisiert.

Auch ein bestandener Durchlauf ist nur für die geprüfte Version, Konfiguration und Aktion aussagekräftig. Nach einer Änderung am Modell, an der Terminlogik oder an einer Integration gehört der Grenzfall erneut in die Prüfung. Auf AgentBrains Seite zu Beispielen und Nachweisen beschreiben wir diese Trennung zwischen Erklärung, Demo und belegtem Einsatz.