Revision 727: Worst of Date/Time Fails, mit Florian Sowade
Diese Folge sprechen wir mit Florian Sowade über eines der zuverlässigsten Rabbit Holes der Softwareentwicklung: Datum und Zeit. Was zunächst nach ein paar Timestamps und Zeitzonen klingt, entwickelt sich schnell zu einer Reise durch Sommerzeiten, historische Kalendersysteme, Schaltsekunden und allerlei politische Entscheidungen, die unsere vermeintlich so präzisen Zeitangaben beeinflussen.
Dabei geht es uns vor allem um ein brauchbares mentales Modell für den Entwickleralltag: Welche unterschiedlichen Arten von Zeitangaben gibt es eigentlich, warum reicht ein einzelner Date-Typ oft nicht aus und wie helfen APIs wie Temporal dabei, die unvermeidbare Komplexität wenigstens explizit zu machen?
Shownotes
- [00:01:05] Datum, Zeit, Zeitzonen und Kalender
Florian unterscheidet als mentales Modell zwischen eindeutigen Zeitpunkten, lokalen Datums- und Zeitangaben, UTC-Offsets und echten Zeitzonen. Warum das wichtig ist, zeigt sich bei der Zeitumstellung, wenn lokale Uhrzeiten gar nicht oder gleich zweimal existieren.
Die Regeln dafür stammen aus der Timezone Database. Zeitzonen können sich durch politische Entscheidungen kurzfristig ändern. Selbst Deutschland besitzt mit Europe/Berlin und Europe/Büsingen zwei Einträge. Für Anwendungen bedeutet das, Zeitzonendaten aktuell zu halten und etwa bei Cronjobs zu berücksichtigen, dass „nachts“ nicht dasselbe ist wie eine feste UTC-Uhrzeit.
Die JavaScript Temporal API macht solche Unterschiede explizit und modelliert verschiedene Zeitkonzepte mit eigenen Typen. Das hilft auch bei Berechnungen: Ein Tag hat durch Zeitumstellungen nicht immer 24 Stunden und drei Monate entsprechen keiner festen Anzahl Sekunden.
Weitere Sonderfälle sind Schaltsekunden und unterschiedliche Kalendersysteme. So werden Shakespeare und Cervantes beide mit dem 23. April 1616 als Todestag geführt, obwohl England und Spanien damals unterschiedliche Kalender verwendeten. Auch Schwedens missglückter schrittweiser Wechsel zum gregorianischen Kalender zeigt, wie schwierig historische Datumsangaben werden können.
Florians Fazit: Annahmen wie „ein Tag hat 24 Stunden“ hinterfragen und möglichst High-Level-APIs und Libraries verwenden, die unterschiedliche Zeitkonzepte ausdrücklich modellieren. Welche Bedeutung eine Zeitangabe konkret hat, bleibt dabei eine Frage der jeweiligen Anwendung.
Links
- IANA Time Zones
Die IANA verwaltet die Time Zone Database mit den weltweit gültigen und historischen Regeln für Zeitzonen und Zeitumstellungen.
- Time Zone Database and Code
Das GitHub-Repository der IANA Time Zone Database enthält die eigentlichen Zeitzonendaten, Regeln, Quelltexte und deren Änderungshistorie.
- Revision 708: Temporal, mit Philipp Dunkel
In Revision 708 haben wir uns bereits ausführlich mit der Temporal API beschäftigt, die eine modernere und robustere Alternative zum klassischen JavaScript-Date-Objekt bietet.