RFC 3339 vs. ISO 8601

Original Article ↗ Hacker News Discussion ↗

“Markdown for time” format (YYYY-MM-DD hh:mm:ss)

  • Some posters like this as a simple, readable, sort-friendly format widely accepted by SQL and many languages.
  • It’s compared to “Markdown for time”: informal but works in many tools, and even LLMs emit it.
  • Others argue it is not computer-friendly because it omits timezone, making it ambiguous and potentially wrong around DST transitions or across systems.
  • It’s also not strictly ISO 8601 (space instead of T, no required timezone per newer editions).

Time zones vs offsets vs UTC

  • One camp: storage should be uniform (typically UTC) and the application handles display in user timezones.
  • Opposing view: always store timezone-aware values; otherwise mixed bad data is inevitable when someone forgets to convert to UTC.
  • Several argue offsets alone (+02:00) are an “anti-pattern”: you usually want either a named zone (e.g. Europe/Paris), a pure instant, or a local time.
  • Another view pushes back: datetime + zone name still isn’t enough for some edge cases; you may also need the offset and even physical location (per RFC 9557–style ideas).

Local/nominal times vs instants

  • Strong debate over whether all date/times should represent instants.
  • One side: most real use cases (meetings, logs, network events) should be instants with explicit zones; “nominal” times without zones cause real-world bugs.
  • Other side: many human-centric cases are inherently “floating” local times (alarms, birthdays, store hours, future appointments whose exact instant depends on where you are or on future political decisions). These cannot always be reduced to a known instant at storage time.

DST, political changes, and edge cases

  • Examples: ambiguous or non-existent local times during DST shifts (e.g. 2025-11-02 01:30 in New York), or regions that change rules or zones (Chile’s Aysén, hypothetical Dnipro/Ukraine scenarios).
  • Some argue local time + location (possibly lat/long) is the only durable model for future physical events; others find that overkill for most systems.

Standards, tooling, and ergonomics

  • Several appreciate the article’s chart showing the overlapping subsets of RFC 3339 and ISO 8601; many formats are seen as redundant or confusing.
  • Complaints: RFC 3339 lacks duration/range syntax; ISO 8601 has too many forms, including very context-dependent ones.
  • ATProto is praised for only allowing the intersection of RFC 3339 and ISO 8601 for simplicity.
  • Practical annoyances: colons and spaces are awkward in shells and filenames (especially on Windows); 24-hour vs 12-hour time and MDY vs YMD vs DMY spark predictable cultural disagreement.