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?
Norddeutschlands größte Developer-Konferenz, seit 2010: 3.500 Entwickler:innen, 100+ Talks, 14 Tracks — von GenAI über Architecture und Security bis Frontend, DevEx und Geek-Out. 90% der Talks ohne Sponsor dahinter, kuratiert von Praktiker:innen statt von Sales-Teams. Auf der Bühne u.a. Eric Evans und Dex Horthy.
Im Ticket enthalten: alle Sessions, à la carte Lunch, Drinks, Popcorn & Nachos und die Party auf der Reeperbahn.
Derzeit spart ihr so richtig, denn es läuft die Crazy Back to Office Aktion. Vom 1.9. – 14.9. bekommt ihr das all-in-one Ticket für 549€ statt 799€.
[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.
1:16:18