Read the previous blog post [0] -- this one is disjointed without it. I dislike TZ selectors that use locations (cities, countries, etc.). Let PDT be PDT(-8) and PST be PST(-7). Why do I need to choose Cupertino, CA (or LA in the blog post example) -- locations over 1k miles away from me? And while I certainly understand where Cupertino is and how it relates to my TZ, what if someone else doesn't? Cupertino isn't a major population center.
Anyway, poor UX. But of course TZ names could also be argued as poor UX. What if you just did PST/PDT as Los Angeles, CA; Oregon, OR, and Seattle, WA all on separate line items? Sure, it's duplicate data but a backend system (Postgres config files, say) should only store the value of the TZ, i.e. -7 / -8. At least a user could recognize 'oh, I drive to xyz major city occasionally, that's the choice I want'.
To keep ranting, I checked macOS 15 TZ selector for PDT/PST. The selector itself is labeled "Closest city". It has numerous locations in California, a few in Nevada, and a couple in Mexico. No cities in Oregon, Washington, or Idaho (and Hyder, AK... neat [1]).
Closest is a stretch, like I said, over 1K miles from LA. But why several California cities, including minor ones like Oceanside (~175K people), but nothing in Oregon (Eugene, also 175K), Portland (652K), or Washington - Tacoma (220K), Seattle (740K). Note I did not look for the smallest city in the macOS CA list.
It's weird to me. Maybe it's because Oregon == Intel and Washington == Microsoft. ;-)
The core issue is that tzdata files do not contain the time zone identifier. If you are unlucky in /etc/localtime is not a symbolic link, you have to scan the files in /usr/share/zoneinfo to find a match. PostgreSQL prefers shorter names: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...
I commented on the other post about how timezones bit me, continue to bite me even though I do everything in UTC now, and will probably bite me again in the future.
I also like that she’s able to reproduce it but I feel like this should have been a test check in the distro to ln the US zones as to not mess up older codebases.
In the end, standardizing is the right way to go. If you’re a maintainer, think about adding tests and checks for files that if moved might break things that depend on it. Maybe a service that watches for fd access to those and gives a warning, I don’t know what the best approach would be but it would be nice to have something at the user land level that said “Ahh ahh ahhh, you didn’t say the magic word”
It's worth noting that a new installation of Debian will still display the same Eastern, Central, Mountain, Pacific menu to the user as shown in the screenshot. It just maps those to the non-deprecated names now.
9 comments
[ 0.19 ms ] story [ 32.1 ms ] threadAnyway, poor UX. But of course TZ names could also be argued as poor UX. What if you just did PST/PDT as Los Angeles, CA; Oregon, OR, and Seattle, WA all on separate line items? Sure, it's duplicate data but a backend system (Postgres config files, say) should only store the value of the TZ, i.e. -7 / -8. At least a user could recognize 'oh, I drive to xyz major city occasionally, that's the choice I want'.
To keep ranting, I checked macOS 15 TZ selector for PDT/PST. The selector itself is labeled "Closest city". It has numerous locations in California, a few in Nevada, and a couple in Mexico. No cities in Oregon, Washington, or Idaho (and Hyder, AK... neat [1]).
Closest is a stretch, like I said, over 1K miles from LA. But why several California cities, including minor ones like Oceanside (~175K people), but nothing in Oregon (Eugene, also 175K), Portland (652K), or Washington - Tacoma (220K), Seattle (740K). Note I did not look for the smallest city in the macOS CA list.
It's weird to me. Maybe it's because Oregon == Intel and Washington == Microsoft. ;-)
[0] https://rachelbythebay.com/w/2025/09/11/debtz/
[1] https://en.wikipedia.org/wiki/Pacific_Time_Zone#United_State...
Debian 13, Postgres, and the US time zones - https://news.ycombinator.com/item?id=45218111 - Sept 2025 (142 comments)
https://rachelbythebay.com/w/2018/04/28/meta/
That's what the authority that defines the zone calls it. Using any other name is adding a useless layer of abstraction.
That's why "US" wins over "America".
I also like that she’s able to reproduce it but I feel like this should have been a test check in the distro to ln the US zones as to not mess up older codebases.
In the end, standardizing is the right way to go. If you’re a maintainer, think about adding tests and checks for files that if moved might break things that depend on it. Maybe a service that watches for fd access to those and gives a warning, I don’t know what the best approach would be but it would be nice to have something at the user land level that said “Ahh ahh ahhh, you didn’t say the magic word”