Neun Jahre auf dem Weg zur Lösung des Zeitproblems in JavaScript: Temporal

 (bloomberg.github.io)
13 Punkte von GN⁺ 2026-03-12 | 7 Kommentare | Auf WhatsApp teilen
  • Die neue Standard-API Temporal, die die Grenzen des Date-Objekts in JavaScript grundlegend ersetzt, hat nach neun Jahren Entwicklung ECMAScript Stage 4 erreicht
  • Temporal bietet immutable Typen, explizite Unterstützung für Zeitzonen und Kalender sowie Nanosekunden-Genauigkeit und beseitigt damit die Unklarheiten und Fehler der bisherigen Date-API
  • Verschiedene Organisationen wie Bloomberg, Igalia, Microsoft, Google und Mozilla arbeiteten bei Spezifikation und Implementierung zusammen; mit der Rust-basierten gemeinsamen Bibliothek temporal_rs wurde eine engineübergreifende Zusammenarbeit ermöglicht
  • Mit differenzierten Typen wie ZonedDateTime, Instant, PlainDate/Time, Duration unterstützt Temporal Zeitberechnungen und die Verarbeitung internationaler Kalender präzise
  • Der Standard, der Probleme aus 30 Jahren löst, gilt als Erfolgsgeschichte für Zusammenarbeit und offene Innovation im JavaScript-Ökosystem

Probleme bei der Zeitverarbeitung in JavaScript und das Aufkommen von Temporal

  • Das bisherige Date-Objekt war eine direkte Portierung von Javas Date aus dem Jahr 1995 und ist seit Jahrzehnten eine Ursache für Bugs gewesen, etwa durch Mutierbarkeit, inkonsistente Monatsberechnungen und mehrdeutiges Parsing
    • Beispiel: Fehler bei der Berechnung des Monatsendes bei Verwendung von setMonth, unterschiedliche Browser-Ergebnisse beim Parsen ISO-ähnlicher Strings
  • Seit den 2010er Jahren verschärften sich die Grenzen von Date, als Webanwendungen komplexer wurden
  • Entwickler kompensierten die Probleme mit externen Bibliotheken wie Moment.js, was jedoch zu größeren Bundles und höherem Wartungsaufwand führte
  • 2017 reichte Maggie Johnson-Pint bei TC39 den Temporal-Vorschlag ein und leitete damit die Standardisierungsdiskussion ein

Zusammenarbeit von TC39 und der Industrie

  • Temporal startete 2018 in Stage 1 und erreichte über neun Jahre hinweg Stage 4 (Standardisierung)
  • Bloomberg beteiligte sich aktiv, um Probleme mit Zeitzonen und Genauigkeit in großen JavaScript-Umgebungen zu lösen
    • Anforderungen: benutzerdefinierte Zeitzonen, historische Genauigkeit auf Basis der IANA-Zeitzonendatenbank, Nanosekunden-Genauigkeit
  • Gemeinsam mit Igalia, Microsoft, Google und Mozilla wurden Spezifikation und Implementierung vorangetrieben
  • Mehrere Ingenieure wie Philipp Dunkel, Ujjwal Sharma, Philip Chimento, Shane Carr und Justin Grant wirkten als Champions mit

Wichtige Typen und Funktionen von Temporal

  • Temporal.ZonedDateTime: immutable Darstellung eines Zeitpunkts mit expliziter Zeitzone, Kalender und DST-Korrektur
    • Beispiel: Wenn beim DST-Wechsel in London 01:30 nicht existiert, wird automatisch auf 02:30 korrigiert
  • Temporal.Instant: Darstellung eines absoluten Zeitpunkts ohne Zeitzone oder Kalender, mit Nanosekunden-Genauigkeit
    • Derselbe Zeitpunkt kann in verschiedene Zeitzonen umgewandelt werden
  • PlainDate / PlainTime / PlainDateTime / PlainYearMonth / PlainMonthDay: „Wanduhr“-Typen ohne Zeitzone
    • Geeignet für einfache Datums-/Zeitanzeigen oder Berechnungen
  • Temporal.Duration: Darstellung von Zeitspannen mit Umrechnung in verschiedene Einheiten (total({ unit: "second" }))
  • Kalenderunterstützung: führt Berechnungen in nicht-gregorianischen Kalendern wie dem hebräischen Kalender präzise aus

Implementierung und Standardisierungsprozess

  • Temporal ist die größte Ergänzung einer Spezifikation in der Geschichte von ECMAScript und umfasst etwa 4.500 Testfälle
  • Es wurde die Rust-basierte gemeinsame Implementierung temporal_rs entwickelt, die von mehreren Engines wie V8 und Boa gemeinsam genutzt wird
    • Vorteile: geringere Einstiegshürden, einfachere langfristige Wartung, höhere Codequalität
  • In den Jahren 2024 bis 2025 erreichte temporal_rs eine Erfolgsquote von 100 % bei den Tests und gilt als gelungenes Beispiel für engineübergreifende Zusammenarbeit

Unterstützungsstatus und künftige Aufgaben

  • Temporal wird bereits von Firefox 139, Chrome/Edge 144 und TypeScript 6.0 Beta unterstützt
    • Safari befindet sich noch im Technical-Preview-Stadium, Node.js 26 ist geplant
  • Die nächste Aufgabe ist die Integration mit Web-APIs
    • Beispiel: Unterstützung von Temporal-Typen in Formularelementen wie <input type="date">
    • Auch eine mögliche Ablösung von DOMHighResTimeStamp wird geprüft (mit einem Beispiel für die Nutzung von Temporal.Now.instant())

Ergebnisse von Zusammenarbeit und offener Innovation

  • Temporal ist ein Standard, der durch neun Jahre institutionsübergreifender Zusammenarbeit fertiggestellt wurde
    • Beteiligt waren unter anderem Microsoft, Google, Mozilla, Bloomberg, Igalia und Boa
  • temporal_rs ist ein erfolgreiches Beispiel für ein Modell gemeinsamer Infrastruktur
    • Es belegt geringere Kosten durch weniger Doppelimplementierungen, mehr Konsistenz und schnellere Innovation
  • Temporal gilt über eine reine API-Verbesserung hinaus als Beleg dafür, dass die JavaScript-Community langfristige technische Schulden gemeinsam abbauen kann
  • Nach 30 Jahren verfügt JavaScript nun über eine moderne API für Datum und Zeit

Verwandte Beiträge

7 Kommentare

 
jeeeyul 2026-03-12

Die Komplexität von Zeitberechnungen rührt weit mehr von Philosophie der Menschheit, der Präzision der Astronomie und kulturellen Einflüssen her als von Fragen des Formats. Rechnen selbst ist auch nur mit long einfach. Auf der Zeitachse gibt es historisch viele Sonderbereiche, in denen 1 + 1 nicht 2 ist, und vieles geht auf Kalender zurück, die wie das I Ging je nach Position variieren, etwa nach dem Winkel von Sonne und Erdoberfläche. In solchen Fällen wurde der koreanische Sonnen- und Mondkalender überhaupt nie auch nur diskutiert.

Und das legt das Korea Astronomy and Space Science Institute fest.
 
tsboard 2026-03-12

Endlich! Wie schön!!
 
shakespeares 2026-03-12

Endlich!!
 
roxie 2026-03-12

ZonedDateTime ...? Du etwa nicht ...!
 
sea715 2026-03-12

Endlich
 
click 2026-03-12

Cs time.h -> Javas java.util.Date -> js Date

Javas joda-time -> JSR 310 -> java.time
-> moment.js -> js Temporal

Das ist also dieser Verlauf.
 
GN⁺ 2026-03-12
Hacker-News-Kommentare
  • Mir gefällt sehr, dass Temporal einen dazu zwingt, die Komplexität des Umgangs mit Zeit richtig zu behandeln
    Durch die Unterscheidung zwischen Instants und kalenderbasierten Datetimes lassen sich viele der typischen Fehler mit Date fast vollständig vermeiden
    Es ist zwar etwas ausführlich, aber immer noch viel besser, als um 3 Uhr morgens wegen eines DST-Bugs aus dem Bett geklingelt zu werden
    • Technisch gesehen dürfte es allerdings fast nur sonntags vorkommen, dass man um 3 Uhr morgens einen DST-Bug beheben muss
  • Ich habe mich in Python auch fast 10 Jahre lang herumgeplagt mit dem Parsen von ISO8601-Datumsangaben
    Ein 2012 gestartetes Issue landete am Ende mit einer Lösung in der Standardbibliothek
    Die Diskussion dazu findet sich in diesem Google-Groups-Thread
    • Ganz ehrlich: danke dafür. Datumsangaben anders als mit fromisoformat zu parsen, fühlt sich inzwischen viel zu unintuitiv an
      Früher habe ich ciso8601 verwendet, aber seit es in der Standardbibliothek ist, ist es deutlich einfacher und robuster
  • Dass Firefox Temporal schon in der Spezifikationsphase implementieren konnte, ist André Bargull (Anba) zu verdanken,
    und besonders beeindruckend ist, dass er die komplette Implementierung tatsächlich allein als Freiwilliger gemacht hat
  • Temporal ist ein großer Fortschritt, aber die API gefällt mir immer noch nicht
    Ich teile Code zwischen Client und Server und versuche deshalb, Daten und Logik strikt zu trennen
    Ich möchte alle Daten als reines JSON halten, damit Serialisierung und Deserialisierung einfach bleiben, aber Temporal-Objekte sind Klasseninstanzen mit Funktions-Properties und daher unpraktisch
    Ein Ansatz wie bei date-fns, bei dem reine Funktionen auf reine Datenobjekte angewendet werden, gefällt mir besser
    • Das ist absichtlich so entworfen. Temporal-Typen lassen sich serialisieren, aber nicht automatisch über JSON.parse wiederherstellen
      Entwickler müssen das korrekte Objekt selbst aus dem ISO-String rekonstruieren
      Eine Automatisierung würde das Risiko erhöhen, mit dem falschen Typ zu arbeiten
      Das Beispiel für einen Temporal.Instant-Reviver in der Doku ist hier hilfreich
    • Ich stoße oft auf dasselbe Problem. Dass bei JSON.parse/stringify der Prototyp verloren geht, ist ein bekanntes Thema
      Trotzdem halte ich die Entscheidung des Temporal-Teams für richtig. Bei Datums- und Zeitlogik ist Typsicherheit wichtiger als ein simpler Daten-plus-Funktionen-Ansatz
      Wenn Operationen an die Objekte gebunden sind, verhindert das, dass ein PlainDate versehentlich wie ein ZonedDateTime behandelt wird
      In Dingen wie tRPC reicht es, an den Grenzen eine dünne Schicht einzuziehen, die Temporal.from() und toString() konvertiert
      Es ist etwas umständlich, aber immer noch besser, als die Typsicherheit aufzugeben
    • Tatsächlich haben auch JavaScript-Date-Instanzen dasselbe Problem
      Es gibt zwar Date.toJSON, aber beim JSON-Parsing muss man Strings wieder in Date umwandeln
      Bei Temporal ist es genauso, und auch date-fns arbeitet am Ende mit nativen Date-Instanzen
    • Alle Temporal-Objekte lassen sich mit .toString() und Temporal.from() leicht serialisieren und deserialisieren
    • JSON.parse so zu verändern, dass es automatisch Temporal-Objekte erzeugt, halte ich für überzogen
      Wie bei Date gilt auch hier 
      serialize: instant.toJSON()
deserialize: Temporal.Instant.from(jsonDate)
      Das sollte explizit so behandelt werden
  • Ich freue mich sehr, dass Temporal angenommen wurde
    Glückwunsch an alle Champions, die so lange daran gearbeitet haben
    Es hat Spaß gemacht, in den letzten Jahren an temporal_rs zu arbeiten
  • Es wäre interessant gewesen, auch den Weg der Verbesserung von Javas Zeit-API zu erwähnen (Joda-Time → JSR 310 → Java 8)
    Da der radikale Vorschlag für JavaScript 2018 kam, frage ich mich, ob Javas Ansatz teilweise Einfluss hatte
    • Ja, man kann es so sehen, dass Joda Moment.js beeinflusst hat und das wiederum in die TC39-Diskussion eingeflossen ist
      TC39 hat Präzedenzfälle aus anderen Sprachen betrachtet, sich aber auf einen für JavaScript optimierten Ansatz geeinigt
      Ich halte diese API für die ausgereifteste Implementierung, die JS-Experten in neun Jahren entworfen haben
    • Stimmt, JavaScript hat aus Java auch die schlechte Version von Date übernommen
      Mehr dazu gibt es auch in diesem HN-Thread
  • Die Bemerkung „In der Mocha-Zeit hat Ken Smith Javas Date-Code nach C portiert“ ist lustig
    weil java.util.Date selbst fast schon ein Port der time.h-API aus C war
  • Ich musste lachen, als ich gesehen habe, dass Safari Temporal nur teilweise unterstützt
    Inzwischen wirkt Safari wie der geistige Nachfolger von IE
    • Safari ist langsam bei der Einführung neuer Funktionen, implementiert sie aber immerhin kontinuierlich
      Das Problem bei IE war nicht die Langsamkeit, sondern dass es aus einer dominanten Position heraus stehen blieb
      Heute sitzt Chrome auf dem imperialen Thron, und Safari und Firefox sind eher noch nötiger
      Die eigentliche Gefahr ist die Zunahme von Chrome-only-Websites
    • Selbst 2026 wird es auf mobilem Safari vermutlich noch keinen nativen Date-Picker geben
  • Ich wünschte, Temporal hätte einen Intervall-Typ 
    const D = new Temporal()
const t = new Interval({minutes:5})
const v = D.add(t)
    • Das ist Duration 
      const D = Temporal.PlainDate.from("2020-06-16");
const t = Temporal.Duration.from({ day: 1 });
const v = D.add(t) // 2020-06-17
      Siehe MDN-Dokumentation
    • Genau, das heißt Duration
  • Danke an das Team, das dafür neun Jahre lang Zeitreisen in 1x-Geschwindigkeit auf sich genommen hat