April 14, 2026

Revision 708: Temporal, mit Philipp Dunkel

56 minutes

Diese Woche haben wir Philipp Dunkel (Bluesky) zu Gast und sprechen mit ihm über Temporal, also die neue JavaScript-API für Datum, Uhrzeit, Zeitspannen und Zeitzonen. Aufhänger ist ein Vortrag von Jason Williams auf der State of the Browser, von dem aus wir in die Geschichte, die Designprinzipien und die praktische Modellierung von Zeit in JavaScript einsteigen.

Unser Sponsor

Alle reden von Automation – aber wo betreibst du eigentlich deine Tools?

Egal ob n8n oder andere Container-Setups: Mit dem Container-Hosting von mittwald läuft deine Anwendung in wenigen Minuten. Die nervige Konfiguration? Geht easy von der Hand – inklusive Vorschlägen für Umgebungsvariablen und Entrypoints.

Also: Fang an zu automatisieren. Dein erster Schritt ist ein Hosting bei mittwald. 👉 mittwald.de/workingdraft

Dabei geht es nicht nur um einen Ersatz für das alte Date-Objekt, sondern auch um die lange Vorgeschichte mit Libraries wie Moment.js, Luxon und date-fns, um die Rolle von Intl und ECMA 402 sowie um die vielen politischen, technischen und semantischen Fallstricke, die bei Datum und Uhrzeit eben dranhängen.

Shownotes

[00:00:54] Temporal

Temporal ist ein neuer API-Komplex für Datum, Uhrzeit, Zeitpunkte, Intervalle und Zeitzonen in JavaScript. Dabei soll es nicht einfach nur ein „besseres Date“ sein. Das bisherige Date-Objekt wird als historisch gewachsener Fehlgriff gesehen, der auf einem frühen, aus Java übernommenen Modell basiert und bis heute viele Probleme mit sich herumschleppt. In der Praxis führte das dazu, dass Entwicklerinnen und Entwickler auf Libraries wie Moment.js, Luxon und date-fns ausweichen mussten. Gerade diese Erfahrungen aus der Library-Welt sind aber in Temporal eingeflossen: Die Maintainer und Champions rund um das Proposal, darunter auch Maggie Johnson-Pint, haben über Jahre hinweg versucht, das Thema Zeit in JavaScript endlich semantisch sauber modellierbar zu machen.Ein zentraler Punkt ist dabei, dass Temporal unterschiedliche Konzepte nicht mehr in ein einziges Universalobjekt presst. Stattdessen gibt es getrennte Typen für das, was wir im Alltag tatsächlich unterscheiden: PlainTime für reine Uhrzeiten, PlainDate für reine Kalenderdaten, PlainDateTime für Datum plus Uhrzeit ohne Zeitzone, MonthDay für wiederkehrende Datumsangaben wie Weihnachten, YearMonth für Monatsangaben und Instant für einen exakten Zeitpunkt auf der Zeitachse. Dazwischen vermittelt ZonedDateTime, das einen Zeitpunkt mit einer Zeitzone verbindet. Dazu kommen Duration und weitere Objekte für Zeitspannen und Berechnungen. Genau diese explizite Trennung ist laut Philipp der eigentliche Fortschritt: Wenn Daten semantisch korrekt modelliert werden, wird auch der Umgang damit sehr viel robuster.

Im weiteren Verlauf geht es um die vielen Randbedingungen, die bei Datums- und Zeitverarbeitung eben nicht bloß technische Details sind. Zeitzonen, Sommer- und Winterzeit, regionale Sonderfälle, politische Entscheidungen und kurzfristige Änderungen machen das Thema notorisch kompliziert. Philipp nennt dafür Beispiele wie Marokko mit Ramadan-bedingten Anpassungen, historische Sonderfälle in Großbritannien oder abweichende Regelungen innerhalb einzelner Länder. Genau deshalb orientiert sich Temporal konsequent an bestehenden Standards und Datenquellen, statt neue Konventionen zu erfinden. Für Zeitzonen wird das IANA-Schema verwendet, für Datums- und Zeitstrings ISO 8601, und die enge Zusammenarbeit mit Intl beziehungsweise ECMA 402 (ECMAScript® internationalization API specification) war ein wichtiger Teil der Arbeit.

Besonders spannend ist die Schilderung des langen Standardisierungswegs. Über neun Jahre hinweg wurde nicht nur am API-Design gearbeitet, sondern auch an Interoperabilität, Spezifikationstext, Tests und Implementierungen. Ein wichtiger Baustein war dabei, die IANA-Zeitzonen-Notation überhaupt in einen relevanten Standardkontext zu bringen, damit sie sauber in Temporal verwendet werden kann. Philipp beschreibt außerdem die lange Stage-3-Phase, in der von außen wenig sichtbar war, intern aber Implementierungen in Browser-Engines und Projekten wie temporal_rs vorangetrieben wurden.

Zu guter Letzt sprechen wir noch über die API-Gestaltung selbst. Dazu gehören die bewussten Namensentscheidungen wie das Präfixe Plain und Zoned, die Immutability aller Objekte, die Vermeidung von versteckten Seiteneffekten und der Anspruch, sinnvolle Defaults zu liefern, ohne Spezialfälle unmöglich zu machen. Gerade bei Rechenoperationen rund um Sommerzeitwechsel oder Monatsarithmetik zeigt sich, warum Temporal so differenziert ist: Es gibt oft nicht die eine „richtige“ Antwort, sondern unterschiedliche fachlich sinnvolle Interpretationen. Temporal soll diese Fälle nicht kaschieren, sondern kontrollierbar machen. Zum Schluss spekulieren wir noch darüber, wie gut sich die API in der Praxis durchsetzt, ob Adapter für bestehende Libraries sinnvoll wären und wann der Punkt erreicht sein wird, an dem man die bisherigen Datumsbibliotheken endgültig hinter sich lassen kann.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

...more