JavaScript Temporal is coming

Original Article ↗ Hacker News Discussion ↗

Timezone Change Detection & Use Cases

  • Several commenters want a timezonechange event so apps can react when system timezones change (e.g., travel, mobiles, desktop apps like Slack adjusting DND).
  • Others argue most apps only need the current timezone at read-time; polling Intl.DateTimeFormat().resolvedOptions().timeZone or getTimezoneOffset already works.
  • Concern raised about fingerprinting, but it’s noted that polling already exposes equivalent information.
  • Consensus: such an event belongs to the browser/host environment, not the Temporal API itself.

UTC vs Time Zones, Past vs Future

  • Strong recommendation to store instants in UTC and convert to local time for display.
  • Multiple people point out this only fully works for past events. For future, human-facing times (meetings, concerts, recurring 12–1 lunch), you must preserve a time zone, not just an offset or timestamp, because tz rules and DST can change.
  • Distinction made between:
    • Past events and machine schedules → UTC is usually fine.
    • Future “human” times → must model civil time + zone (e.g., Europe/Paris).

Temporal Design & Capabilities

  • Temporal is compared favorably to JodaTime/java.time, js-joda, Rust’s Jiff, etc., with separate types for:
    • Instant (absolute time),
    • PlainDate / PlainTime / PlainDateTime (naive, calendar-based),
    • ZonedDateTime (instant + IANA time zone).
  • This separation catches many common bugs (DST issues, “age wrong for one hour” scenarios).
  • Temporal uses RFC 9557-style strings (2025-06-20T17:00:00+02:00[Europe/Paris]), allowing it to:
    • Distinguish fixed-offset vs region-based times.
    • Detect and optionally reject inconsistencies when tz rules change.
  • Time zone data comes from the IANA tzdb via the host; if OS/browser is outdated, you’ll still get outdated rules—same as today.
  • Temporal supports multiple calendars (Islamic variants, Chinese, etc.) and integrates with Intl.DateTimeFormat and Intl.DurationFormat.

Libraries, Polyfills & Ecosystem Impact

  • Many have used the Temporal polyfill in production and report it “solves all issues” of Date, though it’s more complex and somewhat verbose.
  • Moment.js is widely acknowledged as legacy (large, mutable, non-tree-shakeable); Luxon, Day.js, date-fns, js-joda are seen as better but ultimately temporary once Temporal is ubiquitous.
  • Near-term reality: “polyfill everywhere” until browser and Node/Deno/Bun support is broad; some worry about bundle size but Temporal’s polyfill is comparable to (or smaller than) modern date libraries.

Language Evolution, Naming & Skepticism

  • Discussion on why it took ~30 years: backward-compatibility, slow standards, early perception of JS as “toy”, and the complexity of time zones.
  • Some enthusiasm that a standard, long-lived API will finally exist; others are jaded and expect to keep using existing libs for years.
  • The name “Temporal” draws mixed reactions: some find it confusing or too sci‑fi, others argue it’s accurate and avoids collisions with existing Date/Time names and frameworks like temporal.io.