Recreating the US/* time zone situation

Original Article ↗ Hacker News Discussion ↗

City-Based vs Offset-Based Time Zones

  • Some argue TZ pickers should offer simple offsets like PST/PDT (-8/‑7) instead of faraway cities; picking “Los Angeles” when you live 1,000 miles away feels like bad UX.
  • Others counter that offsets alone are insufficient: they don’t encode DST behavior, historical changes, or regional quirks (e.g., Arizona, Indiana).
  • Complaints about which “landmark cities” get entries (e.g., Boise vs. Salt Lake City, no big Texas cities) highlight how arbitrary the current list feels to users.

Why tzdb Uses Cities and Regions

  • Several comments explain tzdb’s rules: a zone is created when a region’s rules diverge (DST dates, offset changes, etc.); the largest city in that region becomes its label.
  • This is why Australian states, Broken Hill, or Boise get entries: they had distinct rules post‑1970. The primary goal is historical and legal accuracy, not UX.
  • City-based zones also handle future political changes (e.g., a state changing DST or offset) better than bare offsets.

UTC vs Local Time on Machines

  • One camp runs everything in UTC (including personal devices), claiming it simplifies logs, travel, and avoids DST clock changes. Several people say they mentally convert to local time.
  • Another camp says UTC on end-user devices is “dumb”: it annoys users, introduces manual conversion errors, and doesn’t inherently fix software bugs.
  • There’s agreement that system internals and logs should usually use UTC or TAI, but display should respect the user’s local zone.

Past vs Future Times and Data Modeling

  • Strong distinction made between:
    • Past instants: best stored as UTC/TAI, never altered.
    • Future “wall times” (meetings, shop hours): should preserve local time + zone (and maybe location) to accommodate later rule changes.
  • Using only UTC for future events can become wrong after tzdata updates; storing only local time can be ambiguous around DST transitions.

Time Zone UX and Auto-Detection

  • Many criticize TZ selectors: poor search (e.g., Google Calendar), odd sorting, missing major cities, confusing abbreviations (EST, PST are overloaded internationally).
  • Some suggest map-based or searchable interfaces; others mention auto-detect via location but push back on privacy and IP-geo inaccuracies.

PostgreSQL/Debian and Naming Issues

  • A technical aside notes tzdata files lack self-identifying zone names; software like PostgreSQL prefers shorter names, so “US/” may win over “America/”.
  • Debian now maps user-facing “Eastern/Central/Mountain/Pacific” to non-deprecated tzdb names, but the underlying renames still surprised the blog author.