Datenmigration: Zeitzonen und Sommerzeit richtig prüfen

Zuerst klären, was das Zeitfeld bedeutet

Ein Zeitfeld kann Messzeit, Eingabezeit, Empfangszeit, Genehmigungszeit oder technisches Änderungsdatum ausdrücken. Diese Bedeutungen dürfen bei der Migration nicht vertauscht werden. Ein Importzeitpunkt im Ziel ersetzt beispielsweise nicht die ursprüngliche Genehmigung. Erfassen Sie daher Feldname, fachliche Definition, Quelle und Nutzung. Prüfen Sie auch, ob ein Feld lediglich ein Datum ohne Uhrzeit beschreibt.

Trennen Sie Zeitpunkt und lokale Darstellung. Ein eindeutiger Zeitpunkt kann in verschiedenen Zeitzonen unterschiedlich aussehen. Umgekehrt kann dieselbe lokale Uhrzeit verschiedene Zeitpunkte bezeichnen. Für den Abgleich wird festgelegt, welche Information erhalten sein muss: tatsächliches Ereignis, damalige lokale Darstellung oder beides. Eine pauschale Regel „alle Datumsfelder in UTC umwandeln“ ist ungeeignet, wenn bestimmte Felder reine Kalendertage oder fachlich vereinbarte lokale Fristen darstellen.

Quellen: [1] [2]

UTC-Abstand und Zeitzonenkennung unterscheiden

Ein UTC-Abstand beschreibt die Differenz für einen bestimmten Zeitpunkt, beispielsweise +02:00. Eine Zeitzonenkennung wie Europe/Berlin verweist auf Regeln, die auch historische Änderungen enthalten können. Die IANA Time Zone Database wird aktualisiert, wenn sich Grenzen oder Regeln ändern. Der aktuelle Abstand allein genügt deshalb nicht für die Interpretation sämtlicher historischer Daten einer Region.

Dokumentieren Sie, welche Regelbasis das Migrationsverfahren verwendet. Prüfen Sie historische Zeiträume und Standorte, die von heutigen Einstellungen abweichen können. Vermeiden Sie mehrdeutige Abkürzungen wie CST ohne weitere Definition. Wenn die Quelle bereits einen eindeutigen UTC-Abstand enthält, behandeln Sie ihn kontrolliert. Wenn sie nur eine lokale Uhrzeit speichert, muss eine geeignete zusätzliche Zuordnung vorliegen. Fehlende Information lässt sich nicht durch eine technisch plausible Vermutung ersetzen.

Quellen: [3]

Durchgerechnetes Beispiel zum Herbstwechsel

Das folgende Beispiel ist konstruiert und verwendet Europe/Berlin nach den geprüften Regeln für 2026. Am 25. Oktober tritt 02:30 Uhr zweimal auf. 02:30 mit +02:00 entspricht 00:30 UTC; 02:30 mit +01:00 entspricht 01:30 UTC. Die lokalen Zeichenfolgen ohne Abstand sehen gleich aus, die Ereignisse liegen aber eine Stunde auseinander. Ein Import, der beide als denselben Zeitpunkt behandelt, verliert diese Unterscheidung.

Für das Frühjahr wird ein anderer Grenzfall geprüft: Am 29. März 2026 ist 02:30 Uhr in Europe/Berlin keine regulär vorkommende lokale Uhrzeit. Das Verfahren braucht eine definierte Behandlung solcher Eingaben. Ein stilles Verschieben auf einen anderen Zeitpunkt wäre eine fachliche Transformation, die nicht unbemerkt erfolgen darf. Die konkreten Kalenderfälle werden für alle relevanten Regionen und Zeiträume aus der eingesetzten Regelbasis abgeleitet; nicht jede Region verwendet dieselben Umstellungstage.

Mehrdeutige und unvollständige Quellen behandeln

Erstellen Sie eine Liste ungeklärter Zeitfelder und bekannter Sonderfälle. Prüfen Sie, ob zusätzliche Daten den Zeitpunkt eindeutig bestimmen: Quellsystemkonfiguration, erfasster Abstand, Ereignissequenz oder ein verbundenes Originalprotokoll. Eine Zuordnung muss nachvollziehbar begründet sein. Die aktuelle Zeitzone eines Servers ist kein ausreichender Beleg dafür, welche Regel bei einer alten Aufzeichnung verwendet wurde.

Wenn die Information nicht zuverlässig rekonstruierbar ist, wird die Unsicherheit ausdrücklich bewertet. Bewahren Sie die ursprüngliche Angabe und kennzeichnen Sie eine abgeleitete Interpretation im geeigneten Konzept. Vermeiden Sie erfundene Sekunden oder willkürliche Sommerzeitzuordnungen nur zur Herstellung technisch eindeutiger Werte. Die Auswirkung auf Prozess, Historie und erforderliche Entscheidung wird von den zuständigen Verantwortlichen beurteilt. Eine erfolgreiche Datenbankkonvertierung schließt diese fachliche Lücke nicht.

Quellen: [1] [2]

Genauigkeit, Reihenfolge und gleiche Zeitpunkte prüfen

Vergleichen Sie Auflösung und Rundungsregeln von Quelle und Ziel. Wenn Millisekunden entfallen, können mehrere Ereignisse denselben dargestellten Zeitpunkt erhalten. Prüfen Sie, ob zusätzliche Sequenznummern oder Beziehungen die notwendige Reihenfolge erhalten. Das Ziel muss nicht zwangsläufig mehr Genauigkeit besitzen als die Quelle; es darf aber keine erforderliche Information unbemerkt verlieren. Ein künstlich präziser Zeitstempel verbessert die historische Wahrheit nicht.

Prüfen Sie die Reihenfolge fachlicher Ereignisse: Ergebnis erfasst, geändert, geprüft und genehmigt. Eine Zeitumrechnung sollte nicht aus einer späteren Genehmigung eine frühere Handlung machen. Berücksichtigen Sie gleichzeitig, dass unsynchronisierte Quellsysteme bereits abweichende Uhren gehabt haben können. Migration und ursprüngliche Zeitqualität sind getrennte Fragestellungen. Korrigieren Sie historische Abweichungen nicht stillschweigend, sondern bewerten und dokumentieren Sie notwendige Maßnahmen.

Quellen: [1]

Transformation und Anzeige getrennt abgleichen

Prüfen Sie den gespeicherten Zeitpunkt und die Oberfläche. Ein Zielsystem kann intern UTC speichern, aber je Benutzerprofil eine lokale Zeit darstellen. Ein Test nur mit dem Profil des Entwicklers deckt andere zugelassene Einstellungen nicht ab. Verwenden Sie die vorgesehenen Rollen und relevanten Regionen. Beschreiben Sie, ob Ausdrucke und Exporte den Abstand oder die Zeitzone eindeutig ausweisen müssen.

Der Referenzabgleich wird unabhängig vom Migrationscode erstellt. Nutzen Sie kontrollierte bekannte Beispiele und geeignete Vergleichsverfahren. Stimmen Quell- und Zielwert erst nach einer definierten Umrechnung überein, wird genau diese Regel belegt. Ein einfacher Textvergleich würde einen korrekten Fall als Fehler melden. Ein Vergleich nur nach Datum kann dagegen einen echten Stundenfehler übersehen. Die Prüfmethode muss zur fachlichen Aussage des Felds passen.

Quellen: [3] [1]

Deltaübernahme und systemübergreifende Ketten berücksichtigen

Während einer Migration können weitere Ereignisse entstehen. Definieren Sie den Cut-off als eindeutigen Zeitpunkt und prüfen Sie dessen Verwendung in allen beteiligten Systemen. Eine lokale Uhrzeit ohne Abstand kann gerade am Umstellungstag eine unklare Grenze erzeugen. Beschreiben Sie, welche Ereignisse vor, auf und nach der Grenze gehören. Testen Sie die Behandlung von Gleichheit und verspätet eingegangenen Nachrichten.

Bei mehreren Systemen prüfen Sie die gesamte Belegkette. ERP, Laboranwendung und Archiv können unterschiedliche Darstellungen verwenden. Eine gemeinsame Suche muss trotzdem die richtige zeitliche Beziehung zeigen. Berücksichtigen Sie Empfangszeiten getrennt von ursprünglichen Ereigniszeiten. Wenn ein Datensatz am Folgetag importiert wird, darf sein fachlicher Ursprung nicht allein wegen des technischen Empfangsdatums verschoben erscheinen. Die Anforderungen an den Nachweis werden vor der produktiven Übernahme festgelegt.

Quellen: [1] [2]

Prüfprotokoll und dauerhafte Recherche

Dokumentieren Sie Feldsemantik, Formate, Regelstand, Umrechnung, Referenzfälle und Befunde. Der Abschluss benennt ungeklärte Quellen und deren Auswirkung. Wenn die Migration eine neue Darstellung einführt, erklären Sie diese für spätere Reviewer. Ein historischer Ausdruck mit 02:30 und eine Zielanzeige mit 00:30 UTC können denselben Vorgang beschreiben; ohne verständliche Regel wirkt dies wie ein Widerspruch.

Bewahren Sie die benötigte Originalinformation und Transformationsbeschreibung nach dem freigegebenen Konzept. Änderungen an Zeitzonenregeln oder Anzeigeprogrammen können historische Darstellungen beeinflussen und brauchen passende Bewertung. Die Eignungsentscheidung sollte erkennen lassen, dass Ereignisse, Reihenfolge und benötigte Genauigkeit erhalten sind. Eine identische Zahl importierter Zeitfelder oder ein fehlerfreier Konvertierungslauf beweist diese Eigenschaften allein nicht.

Quellen: [1]