Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der vor Jahren ausgestellt, nie rotiert wurde und heute noch gültig ist, ist keine Bequemlichkeit. Er ist ein Risiko, das sich seit Jahren niemand mehr angesehen hat.
Warum Zeitzonenfehler meist ein Testproblem sind und kein Datenproblem
Ein Zeitzonenfehler zeigt sich fast nie an einem normalen Dienstag. Er zeigt sich genau in der Woche, in der eine Zeitumstellung stattfindet, oder in einer Region, deren Regierung gerade kurzfristig ihre Regeln für die Zeitverschiebung geändert hat, oder genau an der Grenze zwischen zwei Zonen, wo ein Grenzfall bei der Zuordnung von Koordinaten zu Zonen die falsche Seite wählt. Den Rest des Jahres läuft Code, der schlecht mit Zeitzonen umgeht, ohne jedes sichtbare Problem, und genau das macht diese Fehler so hartnäckig: Der Fehlerfall ist konstruktionsbedingt selten, also wird er selten entdeckt, bevor er tatsächlich in der Produktion auftritt.
Wir glauben, dass die meisten dieser Fehler den Daten angelastet werden, obwohl sie in Wirklichkeit eine Testlücke sind. Die IANA-Zeitzonendatenbank, die den meisten ernsthaften Umsetzungen der Zeitzonenbehandlung zugrunde liegt, auch unserer, erfasst diese Umstellungen und Regeländerungen, sobald sie erfolgen. Dass die Daten verfügbar sind, heißt aber nicht, dass eine Anwendung die Codepfade korrekt durchläuft, die nur in einer Umstellungswoche ausgeführt werden oder nur für die Handvoll Regionen mit ungewöhnlichen Regeln gelten. Wenn eine Testsuite nie eine Zeitumstellung simuliert oder nie eine Abfrage für eine Region mit einer nicht standardmäßigen Verschiebung um eine halbe Stunde oder 45 Minuten ausführt, bewahren korrekte Daten eine Anwendung nicht vor einem Fehler, den nur ihr eigener, ungetesteter Codepfad verhindern kann.
Das ist ein Fall, in dem die Lösung langweilig und konkret ist statt aufregend: Testen Sie ausdrücklich mit den Kalenderdaten, an denen Umstellungen stattfinden, und nicht nur mit einem beliebigen Datum, das gewählt wurde, weil es gerade praktisch war. Testen Sie bewusst mit einer Handvoll Grenzfallregionen mit ungewöhnlichen Verschiebungen und nicht nur mit den gängigen Zeitzonen mit runden Werten, in denen die meiste Entwicklung zufällig stattfindet. Nichts davon erfordert neue Daten. Es erfordert die Entscheidung, dass die seltene Woche genauso sorgfältig getestet werden sollte wie die gewöhnliche, denn die seltene Woche ist genau dann, wenn der Fehler bei einem echten Nutzer auftritt.
Es gibt eine verwandte Falle, die man benennen sollte: die Zeitverschiebung für einen Standort einmal zu cachen und diesen gecachten Wert unbegrenzt weiterzuverwenden. Eine Verschiebung, die im Juli korrekt war, kann im Dezember falsch sein, sobald die Zeitumstellung sie verändert, und ein Cache, der das nicht berücksichtigt, liefert selbstbewusst eine veraltete Antwort, ohne jeden Hinweis darauf, dass etwas schiefgelaufen ist. Auch das ist kein Problem der Datenqualität. Es ist eine Architekturentscheidung, die davon ausging, dass eine Tatsache konstant bleibt, obwohl es gerade im Wesen dieser Daten liegt, dass sie das periodisch nicht tut.
Wir bezeichnen unseren Zeitzonen-Endpunkt als einen der Teile des Produkts, die vollständig funktionieren, weil die zugrunde liegenden Referenzdaten aktiv gepflegt werden und die Abfragelogik so gebaut ist, dass sie diese Umstellungen direkt berücksichtigt, statt eine feste Verschiebung anzunehmen. Der größere Punkt gilt über unser eigenes Produkt hinaus: Ein Zeitzonenfehler, der einen Kunden erreicht, ist selten ein Beweis dafür, dass die Quelldaten falsch waren. Viel häufiger ist er ein Beweis dafür, dass niemand einen Test für die eine Woche im Jahr oder die eine Region geschrieben hat, in der sich die Regeln tatsächlich ändern.