Date is out, Temporal is in

Original Article ↗ Hacker News Discussion ↗

State of Temporal Adoption & Polyfills

  • Several commenters argue the article title is premature: native Temporal support is still very low globally.
  • At the time of discussion, Firefox supports it; Chrome support is just rolling out; Safari/WebKit only has it behind flags; Edge will follow Chromium.
  • Some organizations cannot use it yet because getting polyfills approved is bureaucratically hard.
  • Others note that polyfills exist (notably the js-temporal polyfill at ~51 kB and a lighter ~20 kB one) and are reasonable for servers or apps that can afford the size.

What’s Wrong with Date

  • Core complaints:
    • No real timezone model; everything silently converts to local time.
    • Single mutable object type used for both timestamps and human times, causing subtle bugs when objects are shared or mutated in-place.
    • Inconsistent, surprising parsing rules (e.g. "YYYY-MM-DD" treated as UTC contrary to ISO 8601, two‑digit year heuristics, invalid strings producing an Invalid Date object instead of throwing).
    • Weird normalization (e.g. invalid dates rolling over to the next month) and multiple off‑by‑one traps (zero‑based month, 1900‑based year in some APIs).
  • Some defend Date as “simple enough once learned” and note that its biggest structural flaw is lack of timezone support.

Design and Benefits of Temporal

  • Temporal is praised for:
    • Multiple explicit types: Instant, PlainDate, PlainTime, ZonedDateTime, Duration, etc., matching real concepts like birthdays, deadlines, and schedules.
    • Immutability and value semantics, eliminating many shared‑object bugs.
    • A “correct first” API (inspired by Joda/java.time/Noda) rather than a convenience‑first API.
    • Proper timezone/DST handling; ZonedDateTime can represent “3pm in New York” robustly across serialization.
  • Some find it more complex than libraries like Moment, but see that as reflecting inherent domain complexity.

Browser Compatibility, Web Compatibility, and Versioning

  • There is extensive discussion of how Date’s broken "YYYY-MM-DD" behavior was once “fixed” to match ISO 8601, then rolled back due to web‑compat breakage.
  • Commenters debate alternatives: feature flags, directives like "use strict", versioned language modes, or parallel “fixed” constructors, but note that maintaining multiple modes is costly for browsers.
  • Temporal is framed as the practical “new strict Date” that avoids breaking existing code.

Timezones, Leap Seconds, and Edge Cases

  • Multiple real‑world horror stories: scheduling across timezones, birthdays shifting when users move, off‑by‑one rendering with client‑side formatting.
  • A side thread laments that Temporal, like most datetime APIs, ignores leap seconds and more precise scientific time scales, which makes high‑precision astronomical or GPS‑aligned work difficult in client‑side JS.
  • Others respond that this is a niche concern better served by specialized libraries.