HN Distilled

Essential insights from Hacker News discussions

Debian 13, Postgres, and the US time zones

Original Article

Hacker News Discussion

This Hacker News discussion revolves around a change in Debian's timezone data packaging, specifically moving older, country-based time zone identifiers (like US/*) into a tzdata-legacy package. This has caused breakage for users who were still relying on these deprecated identifiers. The conversation explores the reasons behind the continued use of these old identifiers, the rationale for the change, and general thoughts on timezone management and software distribution practices.

Reasons for Continued Use of Deprecated Timezone Identifiers

A significant theme is the persistence of outdated timezone identifiers despite their deprecation, which occurred as far back as 1995 according to some users. Several factors are cited for this inertia:

  • Muscle Memory and Inertia: Many users and systems have simply relied on these names for decades due to habit and the lack of a compelling push to change. As rtpg put it: "Some of this is surely just muscle memory or inertia as well. I remember random config values from when I was trying out linux boxes back in high school that I replicated into files that just don't get touched for decades afterwards."
  • Lack of Perceived Need/Breakage: Users often avoid changing configurations until a problem forces them to. zahlman explains: "Because of a lack of things compelling people to change them until it causes a breakage. And then when it does cause a breakage, most people would rather move heaven and earth to complain, research workarounds, etc. than just change it."
  • Configuration Defaults and Examples: Old defaults and documentation might still be referencing these deprecated names: pixelesque questions: "Config defaults somewhere still using them? Man page examples? Tutorials using them? Or just force of habit?"
  • Institutional Structures: Changing long-standing configurations within organizations can be complex. zahlman adds: "Institutional structures can also make 'just' changing it far harder than that should be."
  • Intuitive Naming (Perceived or Actual): While the IANA standard favors continent/city names, some users find country and local subdivision names more intuitive, though fredoralive acknowledges this leads to political issues. cpburns2009 also questions the logic: "Why are time-zones even prefixed by continent? Country-prefixed time-zones make more sense because they're defined politically."
  • Easier to Type: Simpler names are sometimes preferred. Macha notes: "I wonder how much of an influence it is that US/Eastern is easier to type than America/New_York."
  • Lack of Awareness: Many experienced sysadmins only became aware of the deprecation through this breakage. js2 states: "Um, I've been a practicing Unix sys admin/devops/sre/developer since 1996 and somehow I missed it until today. And I like to think I generally pay attention to things?" kstrauser echoes this: "I want to do the right thing in such cases, but I’m also learning about this today for the very first time."

Rationale for Timezone Naming Conventions and Deprecation

The discussion delves into why the IANA timezone database (tzdata) shifted from country-based names to continent/city names and why the old names were deprecated.

  • Avoiding Political Entanglements: The primary reason for continent/city naming is to avoid disputes over national borders. mananaysieson explains: "And for most of its life it’s been an explicit policy that timezones are named by continent and representative population center, not by country, to avoid entangling it in territorial disputes and improve naming stability for historical data." phantom784 reinforces this: "That is the logic for using city-based timezone names rather than countries. Country borders change but cities tend to be more stable." umanwizard provides an example: "Nobody can really find fault with Asia/Jerusalem, whereas either Israel/Jerusalem or Palestine/Jerusalem would be controversial."
  • Historical Stability: Cities tend to have more stable identities than countries. phantom784 notes: "Country borders change but cities tend to be more stable."
  • The "backward" file: The US/* identifiers are part of the backward file, a deliberate effort to maintain compatibility with older systems and naming conventions. JdeBP clarifies: "All of the US/* timezone names, such as US/Pacific here, have been backwards compatibility measures".
  • Longstanding Deprecation: These names have been marked as deprecated for a very long time, with yellers pointing out their inclusion in the backward file since 1993.

Debian's Packaging and Communication Practices

Several users express frustration with Debian's handling of this change, particularly regarding communication.

  • Lack of Prominent Release Notes Mention: A key grievance is that this significant change was not clearly highlighted in the Debian 13 release notes. roelschroeven states: "The worst part about this is that it didn't get so much as a mention in the Debian 13 release notes."
  • Reliance on NEWS.Debian: Debian developers point to NEWS.Debian as the designated place for such announcements, which are then usually presented by tools like apt-listchanges. joeyh explains: "NEWS.Debian entries are displayed by apt-listchanges in a pager by default when running apt upgrade, as well as sent by email." However, this mechanism is not always sufficient or noticed by users. nona suggests: "Debian users should use apt-listchanges to display the latest NEWS.Debian items on upgrade."
  • Downstream Patches and Idiocracies: The discussion briefly touches on Debian's practice of patching packages, sometimes for what users perceive as backwards compatibility at the cost of upstream consistency. pfexec criticizes: "Debian is known to have made similar monstrously stupid decisions. For example, they patch OpenSSH source code in a way that makes defaults behave differently than upstream. In the name of backwards compatibility of course."

General Timezone Management and Best Practices

The conversation naturally drifts into broader discussions about managing timezones in software development and system administration.

  • UTC as the Standard: Many advocate for using UTC as the universal standard for storing timestamps to avoid ambiguity and complexity. burnt-resistor advises: "Always run production systems in the Etc/UTC timezone. This eliminates an entire class of problems while only creating minor inconveniences." reactordev describes their approach: "If you want to look at a local window in time, convert the window to a utc start and end date and search. When viewing, use a js function to translate the utc date to a local one to print."
  • The Challenge of Human-Readable Timezones: The inherent difficulty in naming and managing timezones is a recurring theme, often summarized by the joke about the two hard things in computer science: naming and cache invalidation/off-by-one errors. reactordev notes: "Ooofff. The two difficult things in software engineering, naming, and timestamps." dotancohen provides a humorous extension: "And off-by-one errors. The two most difficult things in software engineering: naming things, timestamps, and off-by-one errors."
  • Abstracting Timezones in UIs: For user interfaces, the consensus seems to be that presenting human-friendly labels (like "US Pacific" or "Eastern Time") is better than raw technical identifiers. Symbiote suggests: "For general user interfaces, it's for the user interface to show 'US Pacific' or 'UK' rather than America/Los_Angeles and Europe/London."
  • The Ambiguity of "Local Time": Storing dates as strings without timezone information can lead to ambiguity, especially for future dates where DST rules might change. macintux laments: "But they explicitly or implicitly have also decided not to store the timezone in the strings, so every single value is technically ambiguous." umanwizard points out the limitation of UTC for representing future, intention-based times: "For example: 'this meeting will take place at 10 AM on July 31st, 2026, US Pacific time' cannot be expressed in UTC."

Specific Examples and Anecdotes

The discussion is peppered with personal experiences and examples:

  • Interactive Brokers: evdubs mentions that "Interactive Brokers' Trader Workstation" still uses deprecated US/* timezones and requires tzdata-legacy.
  • GitLab: acdha shares a similar issue with GitLab v18, where unsupported timezones caused scheduled pipelines to stop running.
  • Personal Configuration Habits: Users share how they've maintained old configuration files for years, leading to their recent issues. magicalhippo confesses: "Still typing 'nano -w filename' each and every time since back around y2k..."
  • Historical Timezone Confusion: Anecdotes about past timezone shifts and local variations, like in Indiana in the mid-20th century, highlight the historical complexity of timekeeping. macintux recalls: "I work with a development team who manages data integration and migration for massive datasets, and they have sensibly set a standard that every date/time value they store in their databases will be UTC."

Overall, the discussion highlights the long-tail problem of technical debt, the challenges of maintaining backward compatibility, and the importance of clear communication in software distribution. The move by Debian is seen by some as a necessary cleanup, while others lament the lack of foresight and communication that led to widespread breakage.