Never write your own date parsing library

Original Article ↗ Hacker News Discussion ↗

Birthdates and “local dates”

  • Several commenters argue birthdays aren’t instants in time but calendar labels; storing them as timezone-aware datetimes causes “birthday changes when you move timezones.”
  • Suggested representations:
    • Just store year/month/day (or even a literal string) and never treat it as a timestamp.
    • Use proper “date-only” types (LocalDate/PlainDate) where available rather than timestamps.
    • Some advocate integer days since a fixed epoch for arithmetic; others call this unnecessary and error‑prone unless you truly need it.

Parsing vs Representing Time

  • Parsing is distinct from internal representation: converting between an integer day count and y/m/d is not “parsing” in the same sense as handling arbitrary user text.
  • Many agree that most grief comes from trying to accept too many flexible input formats instead of demanding a strict one.

Ambiguous Formats and UX

  • The MM/DD/YYYY vs DD/MM/YYYY ambiguity is a recurring pain point; multiple people recommend ISO-like YYYY-MM-DD for clarity and lexical sortability.
  • Raw text entry is fragile; date pickers are preferred but can be tedious for distant years unless they support typing and good UX.
  • Locale-sensitive parsing (e.g., 01/02/03) produces wildly different results depending on system locale.

Time Zones, DST, and Politics

  • Time zones and DST are described as fundamentally political, non-systematic, and full of historical quirks and law changes.
  • Examples include DST rules expressed as “first Sunday in March,” variable by year, and zones whose rules change over time.
  • Space/fiction tangents (Mars, galactic calendars, alien days) underline how earth-centric and contingent our assumptions are.

Existing Libraries and JavaScript Pain

  • Many endorse using established libraries (e.g., Moment, Luxon, js-joda, Temporal proposal) rather than rolling your own.
  • Some still like Moment precisely because it’s “done” and stable, despite being deprecated; others complain about mutability and recommend newer options.

ISO 8601, RFCs, and Scoping the Problem

  • ISO 8601 is seen as broad and at times “unhinged” (week dates, ordinal dates, durations, repeating intervals).
  • Several suggest: pick a narrow, unambiguous subset (often RFC 3339-style UTC timestamps) and standardize on that, rather than “support ISO 8601” in full.

“Never write your own X” vs Learning

  • Strong norm: don’t roll your own date/time or crypto for production; the edge cases are endless and mostly tedious, not enlightening.
  • Counterpoint: building such things is valuable for learning; “never” is too strong, as long as you recognize the cost and don’t casually ship half-baked replacements.