Recreating the US/* time zone situation

https://rachelbythebay.com/w/2025/09/12/tz/

by move-on-by • 10 months ago

127 111 10 months ago

p_ing2• 10 months ago

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...

jolmg2• 10 months ago

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.

themafia3• 10 months ago

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.

Terr_6• 10 months 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...

lstodd2• 10 months 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• 10 months ago

Doing this at the system level was one of the better ideas to come out of unix.

p_ing2• 10 months ago

Running UTC as a clock on an end user workstation is about the dumbest thing you can do (unless they reside in UTC).

anonymars2• 10 months ago

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.

Terr_6• 10 months ago

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.

skissane2• 10 months 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• 10 months 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.

secabeen• 10 months ago

But nothing guarantees that there won't be further changes in the future.

There are guarantees that there will be changes in the future! There are changes regularly, some expected, some not. In some countries the suspension of DST due to Ramadan is decided on the first night of Ramadan itself when a group of elders look at the moon and decide whether Ramadan starts tonight, or tomorrow.

https://www.cnn.com/2025/02/27/travel/ramadan-start-crescent...

andrewinardeer• 10 months 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.

laurencerowe• 10 months ago

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.)

sevenseacat• 10 months ago

I remember getting yelled at by an American on Reddit once, when I asked what they meant by EST. Because of course America is the only country that shouldn't have to use country-prefixed versions of anything.

And of course, saying 'EST' doesn't actually tell me what fucking time something is happening. Telling me what UTC offset EST is, does.

lmz• 10 months 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• 10 months ago

I'm curious as to what people in Phoenix would select as their timezone under your proposed solution?

MBCook• 10 months ago

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“.

Sophira3• 10 months ago

This absolutely would happen. Most Americans I know refer to their timezone as EST/CST/MST/PST even after March.

Aloisius3• 10 months 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.

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.

dheera6• 10 months ago

Maybe it could be a forcing function for the less-majority DST-rule countries to align to the majority, once they figure out that their IT systems have trouble twice a year they'll be sure to vote on it.

Ideally though, just get rid of DST.

simonw2• 10 months ago

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...

arccy2• 10 months ago

isn't it at GMT-4 Eastern Time - New York?

jjmarr• 10 months 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?

If your application can access the current location you don't need to expose a TZ selector to the user. You can figure out what time zone database sector you're in automatically.

https://en.wikipedia.org/wiki/List_of_tz_database_time_zones...

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.

Your backend needs to store location because places can switch time zones. The reason for the seemingly arbitrary list of cities is they each define a region where clocks have been synchronized since 1970.

Kwpolska• 10 months ago

I’m not letting applications access my location just to let it pick a time zone.

IP geolocation is often wrong and inaccurate. I’ve had a VPS whose IP was geolocated 360 km away, in another country and time zone. But even with residential IPs, they might be pointing to a different time zone in countries with multiple zones.

1500100900• 10 months ago

Your backend needs to store location because places can switch time zones.

For the event, your backend only needs to store the timestamp in a timestamptz field and make sure that clients set the correct time zone on session start (this you might want the backend to store in the database too, but probably in the users table).

joshka• 10 months ago

I just fired up the selector on macOS Sequoia and I see Seattle, Portland etc. when I type in the combo box (I'm not near there right now). Guessing that you're probably just seeing a ip geolocation that detected your location as further away.

amiga386• 10 months ago

I dislike TZ selectors that use locations (cities, countries, etc.). Let PDT be PDT(-8) and PST be PST(-7).

You can choose that. Set your timezone to Etc/GMT-8. Then, at the exact time your political jurisdiction mandates switching over to PST, go to all your computers and switch them all to Etc/GMT-7. Then do the same thing next year for switching back.

What? That's bad UX as well? Well then, you have to name the correct political jurisdiction that mandates the timezone rules where you live. And that's hard, because so many little tinkerers at state and municipal level decide to change the rules just for their little fiefdom. And they keep changing their minds.

The tz database is looking for the longest-lived identifier that accurately describes that geographic region to which the rules apply. Every time one region diverges from the norm, they need to accommodate the split. They chose continent and city names, because the historical perspective is that city names have remained in use longer than country names.

For your case, however, they have aliases. "US/Pacific" is an alias to America/Los_Angeles", as is "PST8PDT". Set and forget.

dheera6• 10 months ago

You can choose that. Set your timezone to Etc/GMT-8.

In the Debian installer yes, but the stupid Ubuntu installer forces you to pick from a map.

Sophira3• 10 months ago

For your case, however, they have aliases. "US/Pacific" is an alias to America/Los_Angeles", as is "PST8PDT". Set and forget.

Except when you can't forget, as in the original case for this blog post in the first place.

tomhow• 10 months ago

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)

quuxplusone• 10 months ago

Title should involve "US/*", not just "US".

equinoxnemesis• 10 months ago

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/

flomo• 10 months ago

Thanks, I missed it.

(I should note that 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.)

Joker_vD2• 10 months ago

That's the problem with writing posts both of the "everyone else is doing things WRONG, those dang fools" (e.g. the series on RSS readers) and "oops, I did a stupid mistake, heh, TIL" styles and variety: the latter ones tend to attract comments from "The One" (oh noes) referencing the first kind of posts. Naturally, a humble person would simply read them, note them, and move on withouth replying — but a humble would person would not write the "everyone else is doing things WRONG, those dang fools" kind of posts either in the first place; and so we get the third kind of posts, the ones with "yeah, I did a small mistake, but I've admitted it myself, so no one else is allowed to criticize me; anyway..." disclaimer on the top.

P.S. I do distictly remember how a reply on HN to one of her earlier posts on RSS clients mentioned that her laments kinda miguided since her own feed doesn't set one very well-documented and basic cache-controlling HTTP header that most readers actually do respect; but some time later in her later post she described that header as matter-of-fact knowlewdge, no "I've learned about this one recently" remark or anything, and by that time, her RSS feed had started setting it.

jraph• 10 months ago

I don't know, with her RSS saga, she actually provided a tool to test one's RSS feed reader and helped find bugs and this lead to fixes in many RSS tools, making things better for everyone. She put in the work. I find the approach quite constructive.

rlpb• 10 months ago

I'm not sure I understand the purpose of these blog posts for what is, at best, a simple bug in Debian. When I encounter something like this, I find steps to reproduce and file a bug. That's it.

If someone wants to get indignant and broadcast how terrible it is that a project (Debian in this case) is so terrible that they dare have a UX issue that is probably just an oversight, then they're entitled to do that but can also expect pushback where they aren't perfect either.

bityard• 10 months ago

Rachel has been blogging for a long time, she knows what topics get clicks and stir up debate on social media.

themafia3• 10 months ago

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.

bouke• 10 months ago

It is not, that’s the whole point of the blog post this one follows up on.

themafia3• 10 months ago

The United States Government calls it "The Pacific Timezone." They define it, maintain it, and broadcast it's definition. They're the only entity with the authority to do so. That's what I'm using. I'm not using whatever the time happens to be in Los Angeles, I'm using the federal timezone definition. My timezone should absolutely be just "US/Pacific." Using "America/Los_Angeles" is _absolutely_ an abstraction and it's obviously entirely unnecessary.

fweimer2• 10 months ago

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...

That's why "US" wins over "America".

azinman25• 10 months ago

Looking at that code I’m shocked that Postgres allows two-liner if statements without a matching {} (I’m sure someone pedantically will point out that I’m using the wrong terminology or that it was actually several lines of conditionals).

This practice is very bug prone, and has lead to high profile failures like goto fail

yencabulator6• 10 months ago

The project history goes back to 1982. There may have been rewrites in the later 80s, but it's some of the oldest C around, and a very conservative codebase (e.g. Linux kernel gets much more aggressive refactorings regularly).

That particular git repository has history imported from 1996 onward, but Postgres was a very established project by then: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...

These days people might not blink an eye at gofmt/rustfmt rewriting the AST to clean it up, but those toolchains were built that way largley because automating anything about large C codebases is so hard.

machinate2• 10 months ago

What issue are you taking with the code? Line breaks in the condition?

Presumably the last if statement in the diff.

fweimer2• 10 months ago

These days, there are compiler diagnostics for that. There's also a pgindent tool, which will align the visual presentation of the code with its syntactic structure.

reactordev• 10 months ago

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”

joeyh• 10 months ago

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.

swaits• 10 months ago

Cumbersome read. I gave up.

Recreating the US/* time zone situation

Related Stories