Date verschwindet, Temporal kommt

 (piccalil.li)
6 Punkte von GN⁺ 2026-01-13 | 1 Kommentare | Auf WhatsApp teilen
  • Die bestehende Unvollständigkeit und Inkonsistenz des Date-Objekts in JavaScript wird aufgezeigt, und als Ersatz wird die Temporal API vorgestellt
  • Date arbeitet als veränderbares Objekt (mutable object) und weicht damit vom eigentlichen Datumsbegriff ab; zudem gibt es Parsing-Fehler und Grenzen bei der Zeitzonenverarbeitung als strukturelle Probleme
  • Temporal bietet ein neues Modell zur Datums- und Zeitverarbeitung auf Basis von Unveränderlichkeit und umfasst fein aufgeteilte Klassen wie PlainDate, ZonedDateTime und Duration
  • Die Methoden von Temporal verändern bestehende Objekte nicht, sondern geben neue Objekte zurück, wodurch klare und sichere Chaining-Operationen möglich werden
  • Temporal befindet sich derzeit in Standardisierungsstufe 3 (Stage 3) und wird in modernen Browsern wie Chrome und Firefox experimentell unterstützt

Probleme mit dem Date-Objekt in JavaScript

  • Der Date-Konstruktor sorgt mit uneinheitlichen Parsing-Regeln und nicht intuitiver Indizierung für Verwirrung
    • Beispiel: Der Monat beginnt bei 0, während Tag und Jahr bei 1 beginnen
    • Die Zeichenkette "99" wird als Jahr 1999 interpretiert, "100" dagegen als Jahr 0100 — es fehlt also an Konsistenz
  • Date ist auf Zeit (time) zentriert und speichert intern einen Unix-Timestamp (in Millisekunden)
  • Die Unterstützung für Zeitzonen (time zones) ist eingeschränkt; Sommerzeit (DST) oder nicht-gregorianische Kalender werden nicht erkannt
  • Aufgrund dieser Grenzen ist die Abhängigkeit von großen Drittanbieter-Bibliotheken wie Moment.js oder date-fns verbreitet, was zu Leistungseinbußen führt

Konflikt zwischen Unveränderlichkeit und Referenzkonzept

  • Primitive Werte in JavaScript sind unveränderlich und werden als Werte selbst gespeichert, während Objekte (objects) als Referenzen gespeichert und veränderbar sind
  • Date ist ein über einen Konstruktor (constructor) erzeugtes Objekt und daher veränderbar
    • Beispiel: Bei Aufrufen von setMonth() oder setDate() wird das Originalobjekt direkt verändert
  • Dadurch kommt es zwischen Variablen, die auf dasselbe Objekt verweisen, zu unerwarteten Wertänderungen
    • Beispiel: Wenn eine Funktion today als Argument erhält und intern das Datum verändert, wird auch das ursprüngliche today verändert

Temporal: eine neue Datums- und Zeit-API

  • Temporal ist kein Konstruktor, sondern ein Namespace-Objekt (namespace object) mit einer Math ähnlichen Struktur
    • Wichtige Bestandteile: PlainDate, PlainDateTime, PlainTime, ZonedDateTime, Duration, Now usw.
  • Temporal.Now liefert den aktuellen Zeitpunkt in verschiedenen Formen zurück
    • plainDateISO() → Datum im ISO-Format
    • zonedDateTimeISO() → Zeitpunkt inklusive Zeitzone
  • Temporal-Objekte bieten ein klar definiertes Methodensystem
    • Mit add({ days: 1 }), subtract({ years: 2 }) usw. lassen sich Operationen mit expliziten Einheiten ausführen
    • Bestehende Objekte werden nicht verändert, stattdessen wird ein neues Objekt zurückgegeben, wodurch die Unveränderlichkeit erhalten bleibt

Funktionsweise und Vorteile von Temporal

  • Temporal-Objekte sind weiterhin Objekte, folgen aber einem beabsichtigt unveränderlichen Nutzungsmuster
    • Beispiel: today.add({ days: 1 }) gibt ein neues Datumsobjekt zurück, während das ursprüngliche today unverändert bleibt
  • Gegenüber Date bietet Temporal eine knappere und klarere Syntax
    • Beispiel: 
      const today = Temporal.Now.plainDateISO();  
console.log(`Tomorrow will be ${ today.add({ days: 1 }) }. Today is ${ today }.`);  
// 결과: Tomorrow will be 2026-01-01. Today is 2025-12-31.
  • Anforderungen wie Angabe von Zeitzonen, Berechnung von Zeitspannen und Beibehaltung des ISO-Formats werden modern umgesetzt
  • Mit Method Chaining über add, subtract, since, until usw. lassen sich komplexe Datumsberechnungen kompakt ausdrücken

Stand der Standardisierung und Ausblick

  • Temporal hat Stufe 3 (Stage 3) des ECMAScript-Vorschlagsprozesses erreicht, ein Zustand, in dem Browser-Implementierungen empfohlen werden
  • In Chrome und Firefox hat die experimentelle Unterstützung bereits begonnen; andere Browser sollen folgen
  • Entwickler können sich schon jetzt durch Tests und Feedback an der Verbesserung der Spezifikation beteiligen
  • Date wird zwar weiterhin existieren, doch künftig dürfte sich Temporal als Standard für die Datumsverarbeitung etablieren
  • Der Artikel schließt mit dem Hinweis, man hätte es „1995 ersetzen sollen, aber selbst jetzt ist Temporal.Now der richtige Zeitpunkt“

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-13
Hacker-News-Kommentare

  • Dieser Artikel behandelt mehrere absurde Verhaltensweisen des JavaScript-Date-Konstruktors
    Insbesondere wird erklärt, dass das Format 'YYYY-MM-DD' als UTC-Mitternacht interpretiert wird, wodurch sich das Datum in lokalen Zeitzonen um einen Tag verschieben kann
    Nach ISO 8601 sollte eine Angabe ohne Zeitzone ursprünglich als lokale Zeit gelten, aber bei der Ausarbeitung der ES5-Spezifikation wurde sie irrtümlich als „Z“ (UTC) behandelt
    Später wollte man das in ES2015 korrigieren, nahm die Änderung jedoch aus Gründen der Web-Kompatibilität wieder zurück, weil unzählige Websites vom bisherigen falschen Verhalten abhingen
    Details dazu finden sich im Abschnitt Broken Parser

    • Es wäre schön gewesen, wenn es wie bei 'use strict' eine Direktive 'strict datetime' gegeben hätte
      Damit hätte man korrektes Verhalten selektiv aktivieren können, ohne Inkompatibilitäten mit bestehendem Code zu verursachen
      Alternativ wäre auch ein Ansatz denkbar gewesen, bei dem man über ein internes Modul wie import Date from 'browser:date' ein korrigiertes globales Objekt lädt
    • Ich habe früher auch Strings direkt zerlegt, um Datumsobjekte ohne Zeitzone zu erzeugen
      Bei Werten wie Geburtstagen, die einfach nur ein Datum bedeuten, ist es unsinnig, dass sie sich wegen der Zeitzone ändern
      Ich erinnere mich, dass Outlook Geburtstage früher mit Zeitzone gespeichert hat, sodass sie sich beim Umzug in ein anderes Land jedes Mal um einen Tag verschoben haben
    • Die Formulierung „wurde auf dem Altar der Web-Kompatibilität geopfert“ bleibt im Gedächtnis
      Aber hätte es überhaupt eine Alternative gegeben? Wie früher zu IE5-Zeiten browserversionsspezifische Verzweigungen zu erzwingen, wäre wohl noch schlimmer gewesen
    • Auf der Website jsdate.wtf kann man die bizarren Verhaltensweisen von JS Date selbst ausprobieren
    • Wenn man bedenkt, dass solche Probleme die Ursache zahlloser kleiner Bugs sind, ist das zugleich komisch und traurig

  • Ich beneide Rails und Ruby wirklich um ihre Art der Zeitverarbeitung
    APIs wie Time.current.in_time_zone('America/Los_Angeles') + 3.days - 4.months + 1.hour sind intuitiv und mächtig
    Ruby überlädt Time als ein einziges konsistentes Objekt, sodass man sich kaum Gedanken über Konvertierungen oder Casts machen muss
    Ich denke oft, wie schön es wäre, wenn man in JS einfach so etwas wie new Date().add({ days: 1 }) schreiben könnte

    • Allerdings wird infrage gestellt, ob eine Syntax wie „3.days - 4.months + 1.hour“ wirklich gut ist
      Auch darüber, ob das Überladen der Core-Library wirklich ein guter Ansatz ist, lässt sich streiten

  • Schade, dass Safari die Temporal API noch nicht unterstützt
    Hoffentlich kommt die Unterstützung nächstes Jahr

  • Date in JavaScript hat viele Probleme, aber ich glaube nicht, dass die Tatsache, dass es ein Objekt ist, an sich eines der großen Probleme ist
    Ein unveränderliches Objekt wäre besser gewesen, aber dass ein veränderbares Objekt verändert wird, ist an sich keine Überraschung

    • Problematisch ist jedoch, dass anderer Code das Date-Objekt, das ich halte, implizit verändern kann
      Die eigentliche Gefahr von Mutabilität entsteht nicht lokal, sondern durch nichtlokale Änderungen

  • Es ist unpraktisch, dass die Temporal API Schaltsekunden (leap seconds) überhaupt nicht behandelt
    Ich möchte ein JS-Tool für astronomische Berechnungen bauen, dafür werden für UTC-Umrechnungen Daten zu Schaltsekunden benötigt
    Es gibt zwar Umwege wie temporal-tai, aber dann muss man clientseitig eine Schaltsekunden-Datei pflegen, was umständlich ist
    Wegen SOP (CORS-Richtlinie) kann man die Datei auch nicht einfach direkt von externen Websites holen
    Browser werden regelmäßig aktualisiert, daher frage ich mich, warum sie Informationen zu Schaltsekunden nicht eingebaut haben

    • Dass SOP Schaltsekunden-Dateien blockiert, ist ein Missverständnis
      Wenn der Server den Header Access-Control-Allow-Origin setzt oder die Daten als JS-Datei bereitstellt, ist das möglich
      Allerdings kann es aufwendig sein, wenn Browser Schaltsekundendaten selbst mitliefern und pflegen sollen
    • Die Formulierung „arbeitet nur mit UTC“ ist ungenau
      UTC ist ursprünglich eine Zeitskala, die Schaltsekunden einschließt, daher wäre es korrekter zu sagen, dass tatsächlich nur mit POSIX-Zeit gearbeitet wird

  • Im Codebeispiel müsste es statt "33" eigentlich ab "50" heißen, wenn es um die Zuordnung zum 20. Jahrhundert geht — ein einfacher Hinweis auf einen Tippfehler

  • Ich verwende das Temporal-Polyfill und bin bisher sehr zufrieden

    • Allerdings ist es mit 51 KB nicht gerade klein (bundlephobia-Link)
      Für Server oder große Apps ist das in Ordnung, für kleine Apps kann es aber belastend sein
    • Außerdem wird gefragt, wie es sich im Vergleich zu moment oder luxon schlägt

  • Merkwürdigerweise erwähnt der Artikel Date.now() überhaupt nicht
    Für einen Vergleich mit Temporal hätte man die Erklärung an Date.now() aufhängen sollen
    Diese Funktion gibt die vergangene Zeit in Millisekunden seit dem 1. Januar 1970 zurück
    Temporal bietet zwar die benutzerfreundlichere API, aber im Kern geht es darum, die relative Entfernung in der Zeit auszudrücken

    • Allerdings gibt es auch die im Artikel erwähnten timestampbezogenen Bugs
      Dann stellt sich die Frage, wie man in das gewünschte Format konvertiert, ohne den Umweg über Date zu nehmen

  • Es wird noch die kleine, aber wichtige Korrektur angemerkt, dass es nicht „daylight savings time“, sondern „daylight saving time“ heißt

  • Mir war bis jetzt nicht klar, wie kaputt JS Date eigentlich ist

    • Noch bedauerlicher ist, dass diese Probleme seit 1995 bereits klar erkennbar waren
      Wäre man damals nur etwas vorsichtiger gewesen, wären unzählige Entwickler nicht in diese Fallen getappt