Temporal: The 9-year journey to fix time in JavaScript

Original Article ↗ Hacker News Discussion ↗

JavaScript’s long-awaited Temporal API aims to replace the flawed `Date` object with immutable, well-typed time primitives that handle time zones, DST, and calendar math more safely, drawing on lessons from libraries like Joda-Time and NodaTime. Commenters welcome the design and the shared Rust implementation (`temporal_rs`) across engines, expecting it to reduce subtle production bugs and shrink dependence on heavy date libraries. At the same time, they flag concerns about API verbosity, JSON serialization, performance, and the lag before Safari and older runtimes support Temporal widely enough for it to be a default choice.

Overall reception and adoption timeline

  • Many are enthusiastic; several have used the polyfill in production and report it as “well thought-through” and a big improvement over Date.
  • Others are cautious, noting they’ll wait for broad runtime support (Node LTS, Deno, Bun, browsers) before fully adopting.
  • Several expect a multi‑year adoption curve similar to Java’s Joda-Time → JSR 310 transition.

Comparisons to other ecosystems

  • Strong parallels drawn with Java’s Joda‑Time / java.time and .NET’s Noda; Temporal is seen as conceptually similar (immutability, clear types like ZonedDateTime).
  • Some expect Rust to gravitate toward the Temporal model via temporal_rs, possibly influencing or competing with chrono/jiff.

Browser and runtime support

  • Chrome and Deno already ship Temporal; Safari and Firefox lag somewhat, though Safari has work in progress and tech preview support.
  • There’s a heated debate: one side blames Safari for “holding the web back”; another argues Chrome moves too fast and that slower, more cautious implementation (Safari/Firefox) is healthy for standards.
  • Polyfills are widely mentioned as a stopgap, especially for Safari and older corporate browsers.

API design, ergonomics, and philosophy

  • Praised for explicitness: distinct types (Instant, ZonedDateTime, PlainDate, Duration) make DST and scheduling bugs less likely.
  • Criticized for verbosity and complexity: e.g. Temporal.Now.zonedDateTimeISO() vs new Date(), nanosecond precision by default, PascalCase methods.
  • Some argue verbosity is intentional to force developers to be explicit about what kind of “now” they want.
  • Immutability is highlighted as a major improvement over Date’s mutability footguns.

Serialization and JSON

  • Temporal objects serialize cleanly to ISO strings, but JSON round‑trips lose prototypes, requiring explicit reconstruction (Temporal.from, JSON revivers, or helper libraries).
  • Some dislike that this breaks the “plain data over the wire” pattern; others note this is inherent to JSON’s limited types, not unique to Temporal.

Time modeling debates

  • Many advocate the long‑standing “store UTC, convert for display” rule; others note this is insufficient for scheduling and for preserving original time zones/offsets.
  • Temporal’s “Plain” types (date, time, datetime without time zone) and explicit time‑zone handling are seen as valuable for complex scheduling and cross‑zone events.
  • Several comments reiterate how deceptive and difficult real‑world time handling is (DST, calendar systems, leap seconds, religious and political changes).

Implementation details and performance

  • The shared Rust implementation (temporal_rs) used across engines is seen as a notable shift: better interop, but with the risk of shared bugs.
  • A few report poor performance in early experiments and hope optimization work will follow.
  • Temporal’s reliance on Intl for formatting raises concerns about language coverage in Chrome and the need for polyfills.