Eine halbe Stunde später zeigt die Uhr 02:10

Für die Probe haben wir drei Ereignisse eines erfundenen Supporttickets auf den 25. Oktober 2026 gelegt. An diesem Tag springt die Uhr in Berlin von 03:00 Uhr Sommerzeit auf 02:00 Uhr Normalzeit zurück. Für 02:40 sind damit selbst bei bekanntem Datum und der Zeitzone Europe/Berlin zwei Zeitpunkte möglich. IANA-Zeitzonendaten für Europa · RFC 9557, Definition von Zeitzonen

Die drei Ereignisse stehen hier in ihrer tatsächlichen Reihenfolge, jeweils mit Berliner Ortszeit samt UTC-Offset und mit dem Zeitpunkt in UTC.

  1. A · Ticket eingegangen. 02:40:00+02:00 entspricht 00:40:00Z.
  2. B · An die Bereitschaft weitergeleitet. 02:10:00+01:00 entspricht 01:10:00Z.
  3. C · Bestätigung eingegangen. 02:40:00+01:00 entspricht 01:40:00Z.

Welche Angabe im Export stehen muss

Beim Sortieren nach der Ortszeit landet die Weiterleitung vor dem Eingang. Außerdem zeigen A und C dieselbe Ortszeit. In UTC ergibt sich die Reihenfolge A, B, C. Vom Eingang bis zur Bestätigung vergehen 60 Minuten.

Der UTC-Offset gibt an, wie viele Stunden und Minuten die Ortszeit vor oder hinter der koordinierten Weltzeit (UTC) liegt. Für das erste Ereignis wäre 2026-10-25T02:40:00+02:00 ein eindeutiger Zeitstempel. 2026-10-25T00:40:00Z bezeichnet denselben Zeitpunkt direkt in UTC. Beide Schreibweisen entsprechen RFC 3339, einem Standard für Zeitstempel. RFC 3339, UTC-Offsets

Das Zielsystem muss Zeitstempel mit unterschiedlichen Offsets als Zeitpunkte einlesen und nach einer gemeinsamen Zeitbasis sortieren. Als Text sortiert ergaben die drei Zeitstempel mit Offset in der Arbeitsprobe die Reihenfolge B, C, A. RFC 3339, Sortierung

Was nach dem Import stimmen muss

Prüfen Sie die Datei und den Import getrennt. Öffnen Sie den Export zuerst in einem Texteditor. Ist pro Ereignis ein eindeutiger Zeitpunkt hinterlegt? In RFC 3339 erkennen Sie ihn an Datum, Uhrzeit und einem Offset wie +02:00 oder Z für UTC. Wenn die CSV nur 2026-10-25 02:40:00 enthält, suchen Sie im Originalsystem nach einer genaueren Quelle für dieselben Ereignisse, etwa einem API-Export. Halten Sie bei mehrdeutigen Werten fest, für welche Einträge der Zeitpunkt offenbleibt.

Importieren Sie anschließend eine Probe über den tatsächlich vorgesehenen Weg. Wenn Ihre Testumgebung historische Zeitpunkte zulässt, verwenden Sie die drei Beispielereignisse. Andernfalls eignen sich anonymisierte Einträge aus einer wiederholten Stunde, deren ursprüngliche Zeitpunkte Sie kennen. Prüfen Sie anhand der Ereigniskennungen, dass alle Einträge wieder auftauchen. Bei den drei Beispielereignissen muss die Weiterleitung nach dem Eingang stehen und die Bestätigung 60 Minuten nach dem Eingang.

So lässt sich die Arbeitsprobe wiederholen

Wir haben die drei Zeitpunkte mit Python 3.12.13 und den Zeitzonendaten des macOS-Testsystems (2026d) in Europe/Berlin umgerechnet. Das Skript erzeugt zwei Fassungen der Zeitspalte und berechnet die Dauer aus den UTC-Zeitpunkten. Die Abnahme eines konkreten Produkts erfolgt mit dessen eigenem Export und Import.

Laden Sie die Python-Datei unter den Arbeitsmaterialien herunter und führen Sie python3 zeitstempel-probe.py aus. Sie brauchen Python ab 3.9 und IANA-Zeitzonendaten. Oben in der Datei steht die vollständige erwartete Ausgabe. Python-Dokumentation zu `zoneinfo`

Zum Nachlesen

Quellen

  1. IANA Time Zone Database – Europe/Berlin und die EU-Regel zur Zeitumstellung Geprüft am 7. November 2026
  2. RFC 9557 – Begriffe zu Zeitzonen und mehrdeutigen Ortszeiten Geprüft am 7. November 2026
  3. RFC 3339 – Zeitstempel, UTC-Offsets und Sortierung Geprüft am 7. November 2026
  4. Python 3.12 – zoneinfo und Herkunft der Zeitzonendaten Geprüft am 7. November 2026

Mehr zur Auswahl und Einordnung von Quellen steht in unserer Arbeitsweise.

Eine Angabe fehlt oder stimmt nicht?

Hinweis an die Redaktion ↗