JavaScript dates are about to be fixed

Original Article ↗ Hacker News Discussion ↗

JavaScript’s long-troubled Date API is set to be overhauled by the upcoming Temporal standard, bringing first-class support for time zones, precise date math, and interoperability with the IANA database and an emerging IETF timestamp format (RFC 9557). Commenters highlight why naïvely “just using UTC” fails for many real-world cases—like future events, daylight saving rule changes, and financial or geographic context—and welcome a standardized, language-level solution instead of fragmented third‑party libraries. However, there is skepticism about how soon Temporal will actually ship across major engines and how consistently its time zone data will be maintained across platforms.

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).