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

Original Article ↗ Hacker News Discussion ↗

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.