2026-10-19 · Architektur
Wenn die Uhrzeit des Gastes als UTC gespeichert wird
Eine Buchungsplattform sollte von einem Land auf mehrere wachsen. «15:00» muss dann überall 15:00 dort bedeuten, wo die Feier stattfindet. Die Prüfung fand einen Fehler, der in einem Land unsichtbar war.
Die Uhrzeit einer Buchung lag in einer timestamptz-Spalte, also als Zeitpunkt. Hineingeschrieben wurde aber die lokale Uhrzeit des Gastes, gelesen als UTC. Solange die Seite nur in einem Land lief und die Zeit mit derselben Uhr anzeigte, fiel das nicht auf. Eine bis zwei Stunden Verschiebung entstanden erst dort, wo wirklich mit Zeitpunkten gerechnet wird: bei Zahlungsfristen, bei der kostenlosen Stornierung, beim Umrechnen zwischen Zonen.
Altdaten ohne Quelle
Rund 18 000 Zeilen hatten keinen Bezug mehr zu einem Kalenderdatum, aus dem man die Zeit neu berechnen könnte. Was in ihnen steckt, zeigte die Verteilung der Stunden: Die gespeicherten «UTC»-Zeiten haben ihre Spitze bei 14 bis 15 Uhr und streuen von 10 bis 17 — genau die Zeiten, die Gäste für Feiern wählen. Vor und nach der Umstellung des Servers auf UTC sieht das Bild gleich aus. Wären die Werte richtig, läge die Spitze ein bis zwei Stunden früher.
Korrigiert wird nicht mit einem UPDATE. Ein Audit schreibt ein unveränderliches Manifest mit Klasse, altem und neuem Wert jeder Zeile. Die Anwendung läuft dann zeilenweise unter Sperren, prüft alles nach, woraus der Wert berechnet wurde, überspringt Geändertes und lässt sich zurückrollen. Auf einer Kopie der Daten: alle Werte in einem Lauf korrigiert, ein zweites Audit findet null Änderungen.
Drei Runden, zwei Modelle
Zeitpunkte schreibt jetzt nur noch eine Stelle: aus Kalenderdatum und Zone des Ortes. Das Modell dazu haben Claude und Codex unabhängig geprüft, nach den Korrekturen noch zweimal. Gefunden haben sie zwei Regeln für dasselbe (Code und Trigger setzten die Zone unterschiedlich), eine Invariante, die nur der Code hielt und die jetzt als CHECK in der Datenbank steht, einen Deadlock beim Verschieben eines Termins und Buchungen, die bei Zonenwechsel geraten statt einem Menschen vorgelegt wurden.
In der ersten Runde gab es 6 Befunde der Stufe P1 und etwa 15 P2, in der letzten keinen P0. Die Korrekturen selbst hatten zwei neue Fehler gebracht; beide fing die nächste Runde. Vor jeder neuen Einschränkung lief eine Kopie der Produktionsdatenbank: Keine Zeile verletzte sie.
Der Spaltentyp garantiert nicht die Bedeutung des Werts. Und eine Invariante, die nur der Code hält, hält bis zum ersten rohen INSERT.