Debian 13, Postgres, and the US/* time zones

Original Article ↗ Hacker News Discussion ↗

Background: Debian 13 and tzdata-legacy

  • Debian 13 moved many long-deprecated time zone names (including US/*) into a separate tzdata-legacy package, so they’re no longer installed by default.
  • These aliases have been officially “backward-compatibility” names in the IANA tzdb since the early 1990s, maintained via the backward file.
  • The change affects software still using US/* zones (e.g., Postgres configs, Interactive Brokers TWS, some libraries), which now fail until tzdata-legacy is installed or configs are updated.

Why legacy US/* zones are still used

  • Inertia and muscle memory: old configs get copied forward for decades with little scrutiny.
  • Tutorials, examples, and historical defaults reinforced US/* usage.
  • Some find US/Eastern or “US Pacific” more intuitive and aligned with colloquial/official names than America/New_York.
  • Typing convenience (US/Eastern vs America/New_York) may also play a role.

Time zone naming philosophy and politics

  • tzdb explicitly avoids country-based IDs to sidestep border disputes and maintain historical stability; preferred format is continent/ocean + representative city.
  • Country-based names (e.g., US/*, Poland) are kept only as backward-compatibility aliases.
  • City-based IDs also avoid fights over contested places (e.g., Asia/Jerusalem instead of country-prefixed).
  • Some argue country-based names better reflect that time is defined politically; others counter that countries change more than cities.

Debian behavior and communication

  • Some see Debian’s move as overdue alignment with upstream; others call it a “monstrously stupid” breaking change given how pervasive tzdata is.
  • Frustration that such a widely impactful change wasn’t in Debian 13 release notes; maintainers point to per-package NEWS.Debian and tools like apt-listchanges.
  • Broader complaints: Debian’s habit of downstream patching (e.g., OpenSSH, nginx defaults) and the difficulty of tracking those changes.

Operational lessons: UTC, configs, and future times

  • Many advocate running servers in Etc/UTC and storing timestamps in UTC to avoid a class of bugs, with conversion at the edges.
  • Others note UTC alone is insufficient for future events defined in local civil time (DST and law changes).
  • The thread highlights the need to regularly review configs on upgrades (not just copy old files) and to treat time zones as a moving, political target rather than a stable constant.