JavaScript dates are about to be fixed

Original Article ↗ Hacker News Discussion ↗

Overall reaction to Temporal

  • Many welcome Temporal as a long-overdue fix for JavaScript’s notoriously bad Date, especially around time zones and DST.
  • Several note it resembles Java’s Joda-time / java.time, Rust’s chrono/jiff, Rails, etc., and see that as a positive: proven design patterns.
  • Others think the article’s “about to be fixed” claim is overhyped; progress has been slow for years and real-world availability still feels distant.

Why time is hard (and JS Date is worse)

  • Time zone rules change frequently (DST abolition, political shifts); past conversions are stable, but future ones are not.
  • Storing only a UTC timestamp loses context about the original time zone/location and can render future meetings or reservations wrong if rules change.
  • JS Date parsing is inconsistent: new Date(string) only reliably handles a narrow ISO format; V8 additionally supports a tiny list of legacy TZ abbreviations, surprising many.
  • Many apps conflate:
    • absolute time (timestamps/instant)
    • local “wall clock” time (calendar events, birthdays)
    • time zones vs numeric offsets
      leading to DST bugs, missing/duplicated hours, and off‑by‑one‑day errors.

Proposed model and standards

  • Temporal introduces distinct types (e.g., instant, zoned date‑time, plain date) to separate absolute from calendar/clock notions.
  • It is aligned with the IANA time zone database and an IETF standard (RFC 9557) for timestamps with extra info, aiming for cross-language interoperability.
  • For robust scheduling, commenters advocate storing at least: local time, time-zone identifier (e.g., America/Los_Angeles), and often the offset at creation.

Debates: “just use UTC” vs richer representations

  • Some insist UTC timestamps plus (maybe) a stored time zone are enough for almost all applications.
  • Others argue that:
    • for future human events, “just UTC” fails when rules change;
    • for many domains (calendars, financial processes, logs, photos), you need both absolute and local views, sometimes with location-level precision.

Implementation, ecosystem, and remaining wishes

  • Temporal polyfills exist and some teams use them in production, but they’re heavy; many are waiting for native browser/Node support.
  • Concerns remain about:
    • consistent TZ data across runtimes and versions;
    • lack of leap-second querying in web JS.
  • Related API wishes: date‑only types, better formatting (strftime/TR35-style), built‑in relative/duration formatting, and broader numeric types (decimals/integers).