New Date("wtf") – How well do you know JavaScript's Date class?

Original Article ↗ Hacker News Discussion ↗

Unpredictable Date Parsing Behavior

  • Quiz highlights how new Date(string) aggressively finds some interpretation, even for nonsensical or ambiguous strings.
  • Many mappings (e.g., “0” vs “1” vs “2”, strange rules about dots, dashes, partial month names) feel like “random noise” rather than a principled grammar.
  • Date almost never throws; instead it silently returns “valid” but often meaningless dates, so bugs can be subtle.
  • Some participants note you’d never guess these rules; others point out they mostly involve clearly-invalid input.

Engine Differences and Underspecified Behavior

  • Behavior is implementation- and timezone-dependent; quiz is explicitly tied to a specific Node/V8 version and local zone.
  • Firefox is reported to be much stricter, returning Invalid Date for many quiz cases that V8 “helpfully” parses.
  • Other browsers (Safari historically, Chromium-based browsers now) show their own quirks, especially around DST and named time zones.
  • Several comments note much of this parsing behavior is not well-defined by spec and has accreted for web compatibility.

Temporal API and Fix Attempts

  • Temporal is cited repeatedly as the “good news”: a new, stricter date/time API that only accepts RFC-style strings and throws on others.
  • It’s being implemented in major engines and available via polyfills; some would choose a Temporal polyfill for new projects.
  • Skepticism remains that old Date will linger indefinitely for backward compatibility and search-result inertia, adding yet another “standard.”

How Developers Actually Handle Dates

  • Many say they never feed arbitrary user strings to Date, instead:
    • Restricting input (date pickers, validated formats),
    • Using ISO 8601 / Unix timestamps,
    • Or relying on libraries (date-fns, Moment, Luxon, Day.js, etc.).
  • Others counter that a “date parser” should robustly parse unknown strings and fail clearly on invalid input; silently inventing dates is fundamentally broken.

Time Zones and Real-World Complexity

  • Several argue “just use UTC ISO strings” only really works for many past events; future events and scheduling must respect local civil time and evolving timezone rules.
  • Storing both local time and time zone is recommended in such cases; databases often require this anyway.

Broader JavaScript Critique

  • Thread veers into long-standing complaints about JavaScript: type coercion (“false” truthiness), getYear vs getFullYear, mutability, and legacy Java-inspired APIs.
  • Some see this quiz as amusing but mostly impractical; others view it as an illustration of deep design and backwards-compatibility problems.