Zweimal im Jahr passiert in Zeitzonen mit Sommerzeit etwas Merkwürdiges mit der Uhr, das die meiste Software nie berücksichtigt. Wenn die Uhren vorgestellt werden, existiert eine Stunde Ortszeit schlicht nicht, sodass ein Zeitstempel wie „2:30 Uhr“ an diesem Datum nie tatsächlich vorkam. Wenn die Uhren zurückgestellt werden, gibt es eine Stunde zweimal, sodass „1:30 Uhr“ einmal vor und einmal nach der Umstellung vorkam, und ein bloßer lokaler Zeitstempel ohne weitere Information kann Ihnen nicht sagen, welcher gemeint ist.
Das ist kein seltener Sonderfall, der nur für exotische Anwendungsfälle relevant ist. Es ist ein routinemäßiges Kalenderereignis, das jedes Jahr in jeder Zeitzone mit Sommerzeit wiederkehrt, und es bringt unbemerkt jeden Code zum Scheitern, der die Ortszeit als immer eindeutig definiert behandelt. Ein Planungssystem, das „für 1:45 Uhr buchen“ speichert, ohne auch die UTC-Zeitverschiebung zum Zeitpunkt der Buchung zu speichern, kann Monate später nicht wissen, welches der beiden 1:45 Uhr gemeint war, wenn die Buchung auf die Nacht der Umstellung fällt.
Am sichersten ist es, Zeitstempel intern überall in UTC zu speichern und nur für die Anzeige in Ortszeit umzurechnen. UTC kennt keine Sommerzeit und keine Mehrdeutigkeit. Ist ein Zeitpunkt einmal so erfasst, bleibt er korrekt, egal was später mit den lokalen Uhrregeln geschieht. Rechnen Sie erst in dem Moment, in dem Sie die Zeit dem Nutzer anzeigen, in dessen lokale Zeitzone um, und zwar mit den aktuellen Regeln dieser Zeitzone für genau diesen Zeitpunkt. Genau deshalb lohnt sich eine Zeitzonenabfrage, die einen bestimmten Zeitpunkt und nicht nur einen Ort akzeptiert, statt eine Zeitverschiebung einmal zu cachen und immer wieder zu verwenden.
Sonderfälle, die Sie ausdrücklich testen sollten, wenn Sie etwas entwickeln, das Ereignisse plant oder protokolliert: eine Buchung für die nicht existierende Stunde bei der Umstellung auf Sommerzeit, ein Zeitstempel in der doppelten Stunde bei der Rückstellung auf Winterzeit und ein geplantes Ereignis, dessen Datum zwischen seiner Erstellung und seinem Eintreten eine Umstellung überschreitet. Keiner dieser Fälle ist hypothetisch. Sie treten jedes Jahr nach einem festen, vorhersehbaren Zeitplan auf, und sie einmal während der Entwicklung zu testen ist weit günstiger, als ein Support-Ticket über ein Meeting zu debuggen, das sich scheinbar um eine Stunde verschoben hat.
Wenn Ihr System die korrekte Zeitverschiebung für einen bestimmten Zeitpunkt und nicht nur den Zeitzonennamen braucht, fragen Sie sie direkt ab, statt sie aus einem gecachten Wert abzuleiten. Die Zeitzonenabfrage von My Geocode akzeptiert einen bestimmten Zeitpunkt und wendet die Sommerzeitregeln für genau dieses Datum an, sodass die zurückgegebene Zeitverschiebung selbst direkt an der Grenze einer Umstellung korrekt ist.