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. ;-)
> 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.
Because that doesn't tell you when the timezone changes. Two locales can share timezones but start or end daylight savings time at different times.
For instance, Cuba and Florida are both -4 / -5, but Cuba starts and ends daylight savings time 2 hours and 1 hour, respectively, before Florida.
Then there's the fact that locales, once in a while, will change what timezone they're in (like Samoa in 2011) or stop/start observing daylight savings time. Having the timezone set to a place largely solves this problem.
> 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.
There's no America/Salt_Lake_City you're recommended to use America/Boise instead. The people in Salt Lake City are about as far away from Boise as you can get and Salt Lake City is more easily recognized as a landmark then Boise. The process of choosing which cities should be landmark cities comes across as faulty and uninformed.
The reason why certain cities get entries is because sometime after time began (1970-01-01), the region they're in changed their timezone (usually adopting or dropping DST or changing when it began). Those changes need to be recorded in the timezone database. The largest city in the affected area is typically chosen to be representative of the area.
Boise has its own entry because in 1974, the Emergency Daylight Time Act shifted when DST began in Southern Idaho and eastern Oregon. Boise is the largest city in the region.
Technically, if you're in Salt Lake City, you should be using America/Denver, not Boise because of this, otherwise if you say, opened a calendar from 1974, everything will be off by an hour.
If Utah made DST there begin a day earlier this year, Salt Lake City would probably get an entry too.
> The process of choosing which cities should be landmark cities comes across as faulty and uninformed.
I think it's unlikely they're chosen as landmark cities. More likely, timezones were uniform, then some government likely did their own thing in their jurisdiction. The change was then represented as a new timezone named after the place where the change is centered. IOW, the names have more to do with some random divergence that happened at some point in history, rather than what landmarks are the most recognized for today's timezones. Re: Boise & Salt Lake City, maybe Boise was the first to do their own thing while Salt Lake City had a different timezone. Maybe Salt Lake City later decided to adjust their timezone to fit Boise's to facilitate commerce between their states.
Salt Lake City is a 4.5-5 hour drive from Boise. If you want a better example, there are no cities in Texas in the list, and Chicago is a lot further away than Boise is from Salt Lake City!
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.
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.
> Obviously even UTC for a location varies depending on the time of year.
The offset from UTC for a location varies depending on time of year but UTC definitionally has a zero offset throughout the year.
If you’re in the Europe/London time zone your time is equal to GMT/UTC (offset zero) for half the year and BST (offset +1) for the other half.
In other words we have two different types here: Timezones based on location where the UTC offset varies, and the UTC offset itself (like +0100/BST or +0000/GMT/Z.)
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...
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
I suspect a large number of users might choose PST if in California, when they really mean PST/PDT. Or perhaps in the summer they would semi-correctly choose PDT.
Choosing a large city you know shares your time zone does make things a bit more “human“.
Whoah there, no, that's a huge pitfall of sharpened spikes as soon as you deal with events in the future.
If someone proposes an after-work party for "5:30 PM" at the Latverian office in Latverian time, that's not a fixed offset of seconds from now, it's actually a set of triggering conditions.
We can make a decent guess about when those conditions will be satisfied, but don't actually know until it finally happens. At any moment, the administration of Dr. Doom could arbitrarily change the country's clocks. They might skip over that entire hour, or the hour might repeat on that day, or the entire country might cease to exist.
Making a prediction in UTC and storing just that is a very bad idea, because you lost all the original context you need to recalculate a better prediction as things change. Storing the "5PM in Latverian" is how we keep that context.
Here the problem is that past "time" values and future "time" values should be different data types, e.g. "Time" and "FutureTime".
A past time value (e.g. the times of logged events) actually is a time value that is known and it should be stored as a TAI or UTC value and when desired it can be converted to any date/time format for presentation purposes.
In most cases, a future time value is not a known time value yet and it must be stored as a more complex data type, at the minimum including the local time and the time zone, but for more distant future dates preferably also including the exact geographic location, for the eventuality of changes in the time zone laws.
UTC helps store specific moments in time. Notably it does not solve for "dates" nor recurrence. Many of my hairs have been lost to third parties thinking they've created viable systems simply because they use UTC.
It's a similar painful insanity as: "Other currencies? Just convert them to US dollars on save, and store that number in the database, nice and easy, no problems."
Not parent poster, but: It creates annoyance and frustration for the end user, it creates new sources of error (especially when the end-user has to do time-conversions) and provides no actual benefits in terms of system correctness.
Context on "THE ONE", a phrase used in this post, because it wasn't obvious to me initially.
https://rachelbythebay.com/w/2018/04/28/meta/
Thanks, I missed it.
(In my crowd, references to this movie are always super-negative. "The One" gets damned to hell to eternally fight, but never win his battle.)
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. ;-)
[0] https://rachelbythebay.com/w/2025/09/11/debtz/
[1] https://en.wikipedia.org/wiki/Pacific_Time_Zone#United_State...
> 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.
Because that doesn't tell you when the timezone changes. Two locales can share timezones but start or end daylight savings time at different times.
For instance, Cuba and Florida are both -4 / -5, but Cuba starts and ends daylight savings time 2 hours and 1 hour, respectively, before Florida.
Then there's the fact that locales, once in a while, will change what timezone they're in (like Samoa in 2011) or stop/start observing daylight savings time. Having the timezone set to a place largely solves this problem.
> 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.
> The city-based timezone selectors
There's no America/Salt_Lake_City you're recommended to use America/Boise instead. The people in Salt Lake City are about as far away from Boise as you can get and Salt Lake City is more easily recognized as a landmark then Boise. The process of choosing which cities should be landmark cities comes across as faulty and uninformed.
The reason why certain cities get entries is because sometime after time began (1970-01-01), the region they're in changed their timezone (usually adopting or dropping DST or changing when it began). Those changes need to be recorded in the timezone database. The largest city in the affected area is typically chosen to be representative of the area.
Boise has its own entry because in 1974, the Emergency Daylight Time Act shifted when DST began in Southern Idaho and eastern Oregon. Boise is the largest city in the region.
Technically, if you're in Salt Lake City, you should be using America/Denver, not Boise because of this, otherwise if you say, opened a calendar from 1974, everything will be off by an hour.
If Utah made DST there begin a day earlier this year, Salt Lake City would probably get an entry too.
> The process of choosing which cities should be landmark cities comes across as faulty and uninformed.
I think it's unlikely they're chosen as landmark cities. More likely, timezones were uniform, then some government likely did their own thing in their jurisdiction. The change was then represented as a new timezone named after the place where the change is centered. IOW, the names have more to do with some random divergence that happened at some point in history, rather than what landmarks are the most recognized for today's timezones. Re: Boise & Salt Lake City, maybe Boise was the first to do their own thing while Salt Lake City had a different timezone. Maybe Salt Lake City later decided to adjust their timezone to fit Boise's to facilitate commerce between their states.
Salt Lake City is a 4.5-5 hour drive from Boise. If you want a better example, there are no cities in Texas in the list, and Chicago is a lot further away than Boise is from Salt Lake City!
Yep, I pick Chicago for my timezone and it's roughly a 7 hour drive. I think have major cities represent broad timezones is a good UX tradeoff.
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.
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.
> Obviously even UTC for a location varies depending on the time of year.
The offset from UTC for a location varies depending on time of year but UTC definitionally has a zero offset throughout the year.
If you’re in the Europe/London time zone your time is equal to GMT/UTC (offset zero) for half the year and BST (offset +1) for the other half.
In other words we have two different types here: Timezones based on location where the UTC offset varies, and the UTC offset itself (like +0100/BST or +0000/GMT/Z.)
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...
> 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
I suspect a large number of users might choose PST if in California, when they really mean PST/PDT. Or perhaps in the summer they would semi-correctly choose PDT.
Choosing a large city you know shares your time zone does make things a bit more “human“.
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.
My prize for worst time zone UI still goes to Google calendar.
If you want to create an event in a different time zone from your default the select picker it gives you is utterly incomprehensible.
I can't even find the time zone for New York/US eastern in it!
Screenshot here: https://static.simonwillison.net/static/2024/google-calendar...
I'm curious as to what people in Phoenix would select as their timezone under your proposed solution?
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.
> in the end it's a presentation issue.
Whoah there, no, that's a huge pitfall of sharpened spikes as soon as you deal with events in the future.
If someone proposes an after-work party for "5:30 PM" at the Latverian office in Latverian time, that's not a fixed offset of seconds from now, it's actually a set of triggering conditions.
We can make a decent guess about when those conditions will be satisfied, but don't actually know until it finally happens. At any moment, the administration of Dr. Doom could arbitrarily change the country's clocks. They might skip over that entire hour, or the hour might repeat on that day, or the entire country might cease to exist.
Making a prediction in UTC and storing just that is a very bad idea, because you lost all the original context you need to recalculate a better prediction as things change. Storing the "5PM in Latverian" is how we keep that context.
Here the problem is that past "time" values and future "time" values should be different data types, e.g. "Time" and "FutureTime".
A past time value (e.g. the times of logged events) actually is a time value that is known and it should be stored as a TAI or UTC value and when desired it can be converted to any date/time format for presentation purposes.
In most cases, a future time value is not a known time value yet and it must be stored as a more complex data type, at the minimum including the local time and the time zone, but for more distant future dates preferably also including the exact geographic location, for the eventuality of changes in the time zone laws.
UTC helps store specific moments in time. Notably it does not solve for "dates" nor recurrence. Many of my hairs have been lost to third parties thinking they've created viable systems simply because they use UTC.
It's a similar painful insanity as: "Other currencies? Just convert them to US dollars on save, and store that number in the database, nice and easy, no problems."
Running UTC as a clock on an end user workstation is about the dumbest thing you can do (unless they reside in UTC).
Thing is... noone resides in UTC at all.
Let's hear why you think this.
Not parent poster, but: It creates annoyance and frustration for the end user, it creates new sources of error (especially when the end-user has to do time-conversions) and provides no actual benefits in terms of system correctness.
What problem are you thinking it would solve?
Doing this at the system level was one of the better ideas to come out of unix.
Discussion about previous article in series:
Debian 13, Postgres, and the US time zones - https://news.ycombinator.com/item?id=45218111 - Sept 2025 (142 comments)
Title should involve "US/*", not just "US".
> I got to wondering... why did I pick "US/Pacific", anyway?
That's what the authority that defines the zone calls it. Using any other name is adding a useless layer of abstraction.
It is not, that’s the whole point of the blog post this one follows up on.