Lokale Datums- und Zeitangaben in PHP nach UTC zu migrieren, bedeutet nicht einfach, die Zeitzone des Servers zu ändern oder eine feste Anzahl von Stunden abzuziehen. Bevor Sie Daten ändern, müssen Sie feststellen, was jeder Wert bedeutet, in welcher Zeitzone er interpretiert wurde und ob er einen konkreten Zeitpunkt oder eine zivile Regel bezeichnet. Sind diese Fragen nicht geklärt, kann eine automatische Umwandlung die Daten zwar vereinheitlichen, aber trotzdem falsche Ergebnisse liefern.
Am sichersten ist ein schrittweises Vorgehen: zunächst inventarisieren, dann für jeden Datentyp eine Richtlinie festlegen, ein neues Feld hinzufügen, die Daten stapelweise umwandeln und überprüfen und während der Übergangsphase die Lese- und Schreibkompatibilität erhalten. Die Benutzeroberfläche kann weiterhin die gewohnten Uhrzeiten anzeigen, auch wenn die Speicherung künftig Zeitpunkte einheitlich abbildet.
Aktuelle Datums- und Zeitangaben sowie Abhängigkeiten untersuchen
Beginnen Sie damit, alle Quellen für Datums- und Zeitangaben zu ermitteln: Datenbankspalten, Importdateien, Warteschlangen, API-Integrationen und in PHP erzeugte Werte. Prüfen Sie Datentypen und Konventionen: Eine Spalte vom Typ DATETIME speichert üblicherweise Datums- und Zeitkomponenten, ohne selbst die Zeitzone zu bewahren. Bei einem TIMESTAMP können Zeitzonenumwandlungen von der Datenbank-Engine und der Sitzung abhängen. Leiten Sie die Bedeutung nicht allein aus dem Typnamen ab.
Achten Sie auch auf gemischte Formate. Manche Datensätze können beispielsweise lokale Uhrzeiten, andere UTC-Zeiten darstellen; weitere wurden möglicherweise aus einer Quelle importiert, deren Zeitzone unbekannt ist. Vergleichen Sie Stichproben mit externen Ereignissen, dem Audit-Verlauf oder Geschäftsregeln. Prüfen Sie die PHP-Konfiguration, die Zeitzone der Datenbankverbindung sowie Aufrufe von date() oder strtotime(), die von der Standardzeitzone abhängen.
Ein Warnsignal ist, wenn derselbe Wert je nach Server oder lesendem Prozess unterschiedlich angezeigt wird. Ein weiteres ist eine konstante Zeitdifferenz, die sich je nach Jahreszeit ändert: Das kann darauf hindeuten, dass lokale Zeit und UTC vermischt werden und die Sommerzeit eine Rolle spielt.
Zeitpunkte, zivile Datumsangaben und wiederkehrende Zeitpläne unterscheiden
Ein Zeitpunkt ist ein eindeutiger Punkt auf der Zeitachse, etwa der Moment, in dem eine Zahlung bestätigt wurde. Er kann normalisiert und in UTC gespeichert werden; die Zeitzone für die Anzeige wird erst bei der Ausgabe angewendet. In PHP ermöglichen DateTimeImmutable und DateTimeZone, die Quellzeitzone ausdrücklich anzugeben und das Ergebnis umzurechnen:
$local = new DateTimeImmutable($valor, new DateTimeZone('Europe/Madrid'));
$utc = $local->setTimezone(new DateTimeZone('UTC'));Dieses Beispiel ist nur dann gültig, wenn die Eingabe aus Datum und Uhrzeit geprüft wurde und einen eindeutigen Zeitpunkt bezeichnet. Der Konstruktor kann eine nicht existente lokale Uhrzeit beim Wechsel zwischen Sommer- und Winterzeit stillschweigend normalisieren. Bei einer doppelt vorkommenden Uhrzeit kann er eine der beiden Möglichkeiten auswählen, ohne dass die Eingabe dies erkennen lässt. Prüfen Sie vor dem Speichern, ob die Uhrzeit existiert, und legen Sie eine ausdrückliche Richtlinie für doppelte Uhrzeiten fest: Lösen Sie sie beispielsweise anhand eines Offsets oder von Belegen zur Herkunft auf oder markieren Sie den Datensatz zur Prüfung. Lässt sich der Zeitpunkt nicht zuverlässig bestimmen, bewahren Sie den Wert als zivile Angabe auf oder lassen Sie ihn vorläufig offen. Betrachten Sie die Umwandlung nicht allein deshalb als gültig, weil PHP ein Objekt zurückgegeben hat.
Eine zivile Datumsangabe kann dagegen „der 14. April“ lauten, ohne Uhrzeit oder Zeitzone. Geburtstage oder kalenderbasierte Fälligkeitstermine dürfen nicht in einen UTC-Zeitpunkt umgewandelt werden, wenn ihnen das Geschäft keine konkrete Uhrzeit zuordnet: Andernfalls könnte sich bei der Anzeige in einer anderen Zeitzone der Tag ändern.
Ein wiederkehrender Zeitplan wie „Das Meeting findet jeden Montag um 9:00 Uhr in Madrid statt“ beschreibt eine Regel in einer zivilen Zeitzone. Das ist nicht gleichbedeutend damit, jede Woche denselben UTC-Zeitpunkt zu wiederholen, da sich der Zeitversatz der Zeitzone ändern kann. Bewahren Sie die lokale Uhrzeit, die IANA-Zeitzone und die Wiederholungsregel auf und berechnen Sie die nächsten Zeitpunkte anhand dieser Bedingungen.
Die historische Bedeutung vor der Umwandlung rekonstruieren
Für die Umwandlung einer lokalen Datums- und Zeitangabe müssen Sie wissen, welche Zeitzone zum Zeitpunkt ihrer Erfassung galt. Die aktuelle Zeitzone des Benutzers oder die derzeitige Serverkonfiguration reicht nicht aus. Die Anwendung wurde möglicherweise in einer einzigen Zeitzone betrieben, oder die Daten stammen aus verschiedenen Niederlassungen. Suchen Sie nach Belegen in historischen Konfigurationen, der Herkunft des Datensatzes, dem zugehörigen Konto und den damals geltenden Regeln.
Manche lokale Uhrzeiten bezeichnen keinen eindeutigen Zeitpunkt. Wird die Uhr zurückgestellt, kann eine Uhrzeit zweimal vorkommen; wird sie vorgestellt, existieren bestimmte Uhrzeiten nicht. Es kann auch unvollständige Werte geben, etwa eine Uhrzeit ohne Datum oder ein Datum ohne Zeitzone, das importiert wurde. Wandeln Sie solche Werte nicht stillschweigend anhand einer allgemeinen Annahme um: Klassifizieren Sie sie als mehrdeutig, nicht existent oder ohne überprüfbare Herkunft und legen Sie gemeinsam mit dem zuständigen Fachbereich eine Richtlinie fest.
Je nach Fall kann die Richtlinie vorsehen, anhand externer Belege eine der beiden Möglichkeiten auszuwählen, den ursprünglichen Wert als zivile Angabe aufzubewahren oder den Datensatz zur Prüfung zurückzustellen. Dokumentieren Sie die Entscheidung und speichern Sie die IANA-Zeitzone, zum Beispiel Europe/Madrid, nicht nur eine Abkürzung wie „CET“, deren Bedeutung für die Rekonstruktion historischer Regeln unzureichend sein kann.
Eine schrittweise und kompatible Migration entwerfen
Vermeiden Sie es, die einzige verfügbare Spalte sofort zu überschreiben. Fügen Sie ein neues Feld für den normalisierten Zeitpunkt hinzu und, falls die Fachlogik es erfordert, ein weiteres Feld für die Zeitzone oder die ursprüngliche zivile Uhrzeit. Legen Sie im Schema und im Code fest, wofür jedes Feld steht. Ein Name wie starts_at_utc kann hilfreich sein, sofern die Anwendung diese Konvention konsequent einhält.
Legen Sie für Schreibvorgänge während der Übergangsphase eine einzige Quelle der Wahrheit fest. Duales Schreiben kann den Übergang erleichtern, birgt aber das Risiko voneinander abweichender Felder, wenn ein Vorgang nur eines davon aktualisiert. Bündeln Sie diese Logik in einem Schreibpfad, verwenden Sie gegebenenfalls Transaktionen und protokollieren Sie Fehler. Legen Sie für Lesevorgänge eine klare Priorität fest: Verwenden Sie das neue Feld, sobald es verfügbar ist, und greifen Sie nur bei noch nicht migrierten Datensätzen auf das Legacy-Feld zurück.
Begrenzen Sie die Übergangsphase und legen Sie fest, wie ihr Fortschritt gemessen wird. Prüfen Sie vor der Planung der Ablösung, welche Anwendungen, Berichte, Exporte und API-Verbraucher noch das alte Feld lesen. Kompatibilität zu erhalten bedeutet nicht, zwei Interpretationen auf unbestimmte Zeit beizubehalten.
Stapelweise umwandeln und die Transformation überprüfen
Verarbeiten Sie die Datensätze in begrenzten Stapeln, mit stabilen Auswahlkriterien und einer Markierung, anhand derer sich die Arbeit fortsetzen lässt. Die Umwandlung muss wiederholbar sein: Wird ein Stapel erneut ausgeführt, darf ein bereits umgewandeltes Datum nicht ein zweites Mal verschoben werden. Bewahren Sie während der Validierungsphase den ursprünglichen Wert auf und protokollieren Sie die ID, die angenommene Zeitzone, das Ergebnis und etwaige Ausnahmen. Vermeiden Sie dabei, unnötige personenbezogene Daten in technische Protokolle aufzunehmen.
Erstellen Sie vor der Aktualisierung eines Stapels eine Vorschau und prüfen Sie repräsentative Fälle. Vergleichen Sie anschließend die Anzahl der Datensätze, die Werte vor und nach der Umwandlung, Nullwerte und die Verteilung der Fehler. Validieren Sie auch die Eigenschaften der Fachlogik: So sollte etwa eine Reservierung in ihrer Geschäftszeitzone weiterhin dem erwarteten zivilen Datum zugeordnet sein. Eine Zeitdifferenz kann bei einem Zeitpunkt korrekt sein und zugleich einen Fehler anzeigen, wenn sich der Tag einer zivilen Datumsangabe geändert hat.
Halten Sie den Prozess an, wenn die Ausnahmen den vereinbarten Grenzwert überschreiten oder Werte ohne eindeutige Herkunft auftauchen. Korrigieren Sie die Regel oder sondern Sie diese Datensätze zur Prüfung aus. Zwingen Sie sie nicht durch dieselbe Umwandlung wie die überprüfbaren Fälle.
Eingabe, Lesevorgänge und Tests anpassen
Interpretieren Sie Datums- und Zeitangaben an den Eingabegrenzen in der für den Benutzer oder das Geschäft maßgeblichen Zeitzone und validieren Sie das erwartete Format. Wandeln Sie einen Zeitpunkt beim Speichern in UTC um, nachdem die Eingabe die für diese Zeitzone festgelegten Prüfungen auf Existenz und Mehrdeutigkeit bestanden hat. Wandeln Sie den Zeitpunkt bei der Ausgabe in die passende Anzeigezeitzone um. Vereinbaren Sie für APIs ein eindeutiges Format, etwa einen Zeitstempel mit Zeitzonenangabe, und dokumentieren Sie, ob Felder Zeitpunkte oder zivile Werte darstellen.
Tests sollten explizite Zeitzonen und Fälle rund um die saisonalen Zeitumstellungen enthalten: nicht existente und doppelte Uhrzeiten, Mitternacht, Tagesgrenzen und Umwandlungen zwischen Zeitzonen. Ergänzen Sie Hin- und Rücktests: Interpretieren Sie eine Eingabe, speichern Sie den Zeitpunkt, zeigen Sie ihn erneut in der ursprünglichen Zeitzone an und prüfen Sie, ob die erwartete Bedeutung erhalten bleibt. Verlangen Sie nicht, dass die Textdarstellung immer identisch ist, wenn die Ausgabe normalisiert wird; prüfen Sie die Komponenten und die Semantik. Nehmen Sie außerdem Tests auf, die bestätigen, dass eine nicht existente Uhrzeit abgelehnt oder gemäß der Richtlinie behandelt wird und eine doppelte Uhrzeit nicht ohne die vorgesehene Regel aufgelöst wird.
Checkliste für die Ablösung des Legacy-Felds
- Jedes Feld wurde als Zeitpunkt, zivile Datumsangabe oder wiederkehrende Regel klassifiziert.
- Die Quellzeitzone ist dokumentiert, und für mehrdeutige Fälle gilt eine ausdrückliche Richtlinie.
- Neue Schreibvorgänge halten sich an eine einzige Quelle der Wahrheit, und für kompatible Lesevorgänge ist ein Ablösetermin festgelegt.
- Die stapelweise Umwandlung kann fortgesetzt werden und protokolliert Ausnahmen nachvollziehbar.
- Die Tests decken Zeitumstellungen, Tagesgrenzen, APIs und die Anzeige in verschiedenen Zeitzonen ab.
- Berichte, Exporte, geplante Aufgaben und Integrationen hängen nicht mehr vom Legacy-Feld ab.
Lösen Sie das alte Feld erst ab, wenn die Migration validiert ist und keine Verbraucher mehr von seiner Interpretation abhängen. UTC für Zeitpunkte, IANA-Zeitzonen für zivile Regeln und eine eindeutige Semantik für jedes Feld reduzieren Mehrdeutigkeiten, ohne dass die Benutzeroberfläche interne Details der Speicherung offenlegen muss.
