Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

Original Article ↗ Hacker News Discussion ↗

JavaScript’s handling of dates—where strings like `2025/05/28` and `2025-05-28` can resolve to different instants—highlights long‑standing quirks in its `Date` API, inconsistent parsing rules, and browser differences. Commenters trace these problems to historical compromises in both JavaScript and web standards, contrast them with newer proposals like the Temporal API, and swap best practices around UTC, time zones, and ISO/RFC3339 formats. More broadly, the conversation underscores how deceptively complex time and date handling is, and how legacy behavior and compatibility pressure have locked the web into fragile conventions.

JavaScript Date Parsing & “Undefined” Behavior

  • The core issue: new Date('2025/05/28') and new Date('2025-05-28') are specified differently.
  • The spec only guarantees behavior for ISO-like strings; other formats are explicitly left to implementations, so browsers can interpret them however they like.
  • Slash formats like 2025/05/28 are treated as legacy, local-time dates; dash ISO-like ones may involve time zones and are handled differently.
  • Some see this as “undocumented undefined behavior”; others point out it is documented as implementation-defined, just surprising.

Legacy of Date and the Temporal Fix

  • JS Date inherits design problems from Java’s java.util.Date (zero-based month, bad constructors, etc.).
  • Java deprecated most Date constructors; JS can’t, due to web compatibility.
  • The upcoming Temporal API is viewed as the proper fix, with explicit types:
    • Instant (timestamp), ZonedDateTime (timestamp + zone), PlainDateTime / PlainDate / PlainTime, plus Duration.
  • Some compare these to PostgreSQL timestamptz, timestamp, date, time, and interval.

Why the Web Runs on This Anyway

  • Historical path dependence: JS was “the toy language” shipped in browsers while heavier plugin-based stacks (Java applets, Flash, Silverlight) failed due to security, performance, and crash issues.
  • Despite a weak early standard library (even Node.js started on ES3), browser ubiquity and incremental improvements made JS the de facto web language.

Browser Monoculture & Standards Politics

  • Debate over whether a single dominant browser plus strong standard library would be better or worse than today’s de facto Chrome/Safari duopoly.
  • Temporal’s rollout illustrates how one dominant engine can effectively gate new language features.
  • The date-string behavior got locked in after complaints that spec-conforming changes in Chrome were “breaking,” eventually pushing the spec toward legacy behavior.

Dates, Time Zones, and Best Practices

  • Strong consensus: date/time handling is hard everywhere; never rely on generic “auto-parse” of arbitrary date strings.
  • Recurrent advice:
    • Distinguish absolute timestamps vs. calendar/clock times; store the correct concept.
    • Use explicit parsing/formatting functions and high-level APIs, not manual string hacking.
    • “Just use UTC” is not a universal solution: you may need to store original time zone (and sometimes location) for meetings, logs, or legal/UX reasons.
    • For pure calendar dates (e.g., birthdays, age checks), store date-only types; timestamps and time zones are often irrelevant or misleading.

ISO 8601, RFC3339, and Human Formats

  • Many advocate ISO 8601 YYYY-MM-DD (or RFC3339) as the only sane interchange format.
  • Others note ISO 8601’s permissiveness and odd variants; RFC3339 is praised for being stricter and freely accessible.
  • There’s extended debate on separators (- vs /), regional formats (MDY, DMY, YMD), and how easily ambiguity creeps in.

Frustration, Humor, and War Stories

  • Multiple anecdotes of bugs caused by JS silently attaching local midnight to date-only values, shifting days when converted to UTC.
  • Calls for separate “Day” or local-date types and for languages to avoid forcing every date into a timestamp-plus-time-zone model.
  • Links to classic “WAT” talks, xkcd, and “falsehoods programmers believe about time” underline that these problems are pervasive and longstanding, not unique to JS.