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. ;-)
> 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)
Whether daylight savings time is being used at a given location at a given time of year is a matter of government policy. The city-based timezone selectors should handle that automatically based on the jurisdiction you choose.
> 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.
Then the time may be wrong for half the year depending on where you are.
Terr_•1h ago
A bit of an edge case, but there's also the problem that the time zone you pick today might not be the time zone you have tomorrow: The jurisdiction you're in can change what their clocks use on an institutional whim.
It's very unlikely, but tomorrow some state or major city in PST could decide to add 15 minutes to all their wall clocks. Should your computer's clock change? That depends on what you're using it for...
lstodd•1h ago
if one is serious, one just chooses UTC.
one can play with timezones all they want, but in the end it's a presentation issue.
somat•53m ago
Doing this at the system level was one of the better ideas to come out of unix.
p_ing•31m ago
Running UTC as a clock on an end user workstation is about the dumbest thing you can do (unless they reside in UTC).
lstodd•29m ago
Let's hear why you think this.
skissane•1h ago
> Let PDT be PDT(-8) and PST be PST(-7)
The problem is both the US and Australia have “EST/EDT” - the Australian version sometimes has an A stuck on the front to disambiguate it from the US timezone, but that isn’t always done (especially given some systems insist timezone abbreviations can be max 3 characters). And the problem with disambiguating on the basis of UTC offsets is you’d be surprised by how many people have no clue what any of them are. But “Americas” vs “Australia”, they’ll get that right
bbanyc•1h ago
You can't just go by time zone names because there are weird exceptions, like most of Arizona not doing DST. Then there's Indiana, which didn't do DST until 20 years ago, and there are some counties that switched time zones when the DST law took effect... if you're in one of those counties will you just accept old timestamps being an hour off? Granted, this gradually becomes less of an issue the further we get from the change. But nothing guarantees that there won't be further changes in the future.
And that's just the US, there's almost 200 other countries each with their own laws.
andrewinardeer•1h ago
Even abbreviations have issues. PST (UTC+8) is also Philippine Standard Time. EST could mean Eastern Standard Time in Australia, granted that nowadays is AEST.
Timezones are such a headache. Obviously even UTC for a location varies depending on the time of year.
Even the International Space Station shifted timezones from Houston time to UTC+0.
Curiosity and Perseverance's clocks are UTC but operations run on LMST (local mean solar time) Gale Crater and LMST Jezero Crater- their landing locations. That point is moot until humans start spinning up VMs on Mars which they will one day.
lmz•5m ago
Offset alone is not enough because different TZ names also point to different DST schedules (current and historic) and past changes.
You can look at the tz data files to see what that looks like.
Bratmon•4m ago
I'm curious as to what people in Phoenix would select as their timezone under your proposed solution?
p_ing•10h ago
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. ;-)
[0] https://rachelbythebay.com/w/2025/09/11/debtz/
[1] https://en.wikipedia.org/wiki/Pacific_Time_Zone#United_State...
jolmg•1h ago
Whether daylight savings time is being used at a given location at a given time of year is a matter of government policy. The city-based timezone selectors should handle that automatically based on the jurisdiction you choose.
> 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.
Then the time may be wrong for half the year depending on where you are.
Terr_•1h ago
It's very unlikely, but tomorrow some state or major city in PST could decide to add 15 minutes to all their wall clocks. Should your computer's clock change? That depends on what you're using it for...
lstodd•1h ago
one can play with timezones all they want, but in the end it's a presentation issue.
somat•53m ago
p_ing•31m ago
lstodd•29m ago
skissane•1h ago
The problem is both the US and Australia have “EST/EDT” - the Australian version sometimes has an A stuck on the front to disambiguate it from the US timezone, but that isn’t always done (especially given some systems insist timezone abbreviations can be max 3 characters). And the problem with disambiguating on the basis of UTC offsets is you’d be surprised by how many people have no clue what any of them are. But “Americas” vs “Australia”, they’ll get that right
bbanyc•1h ago
And that's just the US, there's almost 200 other countries each with their own laws.
andrewinardeer•1h ago
Timezones are such a headache. Obviously even UTC for a location varies depending on the time of year.
Even the International Space Station shifted timezones from Houston time to UTC+0.
Curiosity and Perseverance's clocks are UTC but operations run on LMST (local mean solar time) Gale Crater and LMST Jezero Crater- their landing locations. That point is moot until humans start spinning up VMs on Mars which they will one day.
lmz•5m ago
You can look at the tz data files to see what that looks like.
Bratmon•4m ago