8 ms·

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

by p_ing 1y 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/ https://rachelbythebay.com/w/2025/09/11/debtz/ [1] https://en.wikipedia.org/wiki/Pacific_Time_Zone#United_States https://en.wikipedia.org/wiki/Pacific_Time_Zone#United_State...

amiga386 1y 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.
- dheera 1y 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.
  - mindslight 1y ago
    If the map let you pick any arbitrary point rather than having to pick a specific city in the TZ database, that would actually be a better way than a list of cities. See the discussion elsewhere in this thread about mapping Salt Lake City -> (Boise vs Denver). (I don't think the TZ database contains the information to do this though, but maybe it should?)
  - prmoustache 1y ago
    The good option is not to yell at clouds but to open a bug report, provide a patch, use Debian or change it after install.
    - dheera 1y ago
      I change it after install, but let's be realistic: I'm not Linus Torvalds or Guido von Rustum, it's not like they would listen to me or take my patch.
  - layer8 1y ago
    Why would you use Ubuntu in the first place?
    - dheera 1y ago
      Because it works? Why wouldn't you?
- Sophira 1y 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.
deleted 1y ago
[deleted]
jolmg 1y 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.
- themafia 1y 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.
  - dheera 1y ago
    I run all my clocks and computers in UTC. I hate that I have to select "Reykjavik" in the Ubuntu installer instead of just "UTC".
    - accrual 1y ago
      Have you had any interesting pros/cons to running your clocks UTC?
  - jen20 1y ago
    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!
    - DangitBobby 1y ago
      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.
Terr_ 1y 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 1y 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 1y ago
  Doing this at the system level was one of the better ideas to come out of unix.
  - yencabulator 1y ago
    In an operating system especially good for multi-user remote access, why would you assume all your users are in the same timezone? Timezone is very much a user interface issue.
- p_ing 1y ago
  Running UTC as a clock on an end user workstation is about the dumbest thing you can do (unless they reside in UTC).
  - dheera 1y ago
    I do this on all my workstations, phones, wall clocks, Google calendar, and everything. After a lot of frustration I found it the lesser of evils to just think in UTC regardless of where I am in the world, and convert for local people on the fly.
  - lstodd 1y ago
    Let's hear why you think this.
    - Terr_ 1y ago
      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?
skissane 1y 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 1y 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 1y 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-moon-sighting https://www.cnn.com/2025/02/27/travel/ramadan-start-crescent...
andrewinardeer 1y 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.
- deleted 1y ago
  [deleted]
- laurencerowe 1y 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 1y 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 1y 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 1y ago
I'm curious as to what people in Phoenix would select as their timezone under your proposed solution?
MBCook 1y 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“.
- Sophira 1y ago
  This absolutely would happen. Most Americans I know refer to their timezone as EST/CST/MST/PST even after March.
  - macintux 1y ago
    I’m currently working at one of the world’s largest consumer banks, and for a company that really should care about the accuracy of such things, I see “EST’ frequently all summer long.
    - gerikson 1y ago
      In my experience, Brits refer to their time as "GMT" whether or not DST is in effect.
      - Sophira 1y ago
        True; I should have said "most people refer to their local timezone in that way". (The reason I didn't was because at the time, I was referring to those specific timezones, not because I was picking on Americans.)
Aloisius 1y 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.
- dheera 1y 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.
simonw 1y 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-timezones.jpg https://static.simonwillison.net/static/2024/google-calendar...
- arccy 1y ago
  isn't it at GMT-4 Eastern Time - New York?
  - simonw 1y ago
    Here's the search results you get if you type "eastern" in that interface: https://gist.github.com/simonw/c2a73e40bbc87b8c25333207c551f7af?permalink_comment_id=5759017#gistcomment-5759017 https://gist.github.com/simonw/c2a73e40bbc87b8c25333207c551f... Typing "New York" gets zero results. Even knowing the exact name of the timezone I want I still can't find it in that UI!
    - arccy 1y ago
      At least for me, since it's ordered by offset, i just scroll to the approximate offset rather than try to type. On android, "eastern" similarly results in a mess of results (but eastern is a bad name anyway...), "new york" does find it.
    - yencabulator 1y ago
      The desktop web version seems to have no type-in search functionality. In the Android app typing "new y" gives Eastern Daylight Time 18:30 GMT-4 United States, *New Y*ork
jjmarr 1y 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#/media/File:Timezone-boundary-builder_release_2023d.png 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 1y 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 1y 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 1y 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.

by p_ing 1y ago

amiga386 1y 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.

dheera 1y 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.
- mindslight 1y ago
  If the map let you pick any arbitrary point rather than having to pick a specific city in the TZ database, that would actually be a better way than a list of cities. See the discussion elsewhere in this thread about mapping Salt Lake City -> (Boise vs Denver). (I don't think the TZ database contains the information to do this though, but maybe it should?)
- prmoustache 1y ago
  The good option is not to yell at clouds but to open a bug report, provide a patch, use Debian or change it after install.
  - dheera 1y ago
    I change it after install, but let's be realistic: I'm not Linus Torvalds or Guido von Rustum, it's not like they would listen to me or take my patch.
- layer8 1y ago
  Why would you use Ubuntu in the first place?
  - dheera 1y ago
    Because it works? Why wouldn't you?
Sophira 1y 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.

deleted 1y ago

[deleted]

jolmg 1y 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.

themafia 1y 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.
- dheera 1y ago
  I run all my clocks and computers in UTC. I hate that I have to select "Reykjavik" in the Ubuntu installer instead of just "UTC".
  - accrual 1y ago
    Have you had any interesting pros/cons to running your clocks UTC?
- jen20 1y ago
  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!
  - DangitBobby 1y ago
    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.

Terr_ 1y 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 1y 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 1y ago
Doing this at the system level was one of the better ideas to come out of unix.
- yencabulator 1y ago
  In an operating system especially good for multi-user remote access, why would you assume all your users are in the same timezone? Timezone is very much a user interface issue.
p_ing 1y ago
Running UTC as a clock on an end user workstation is about the dumbest thing you can do (unless they reside in UTC).
- dheera 1y ago
  I do this on all my workstations, phones, wall clocks, Google calendar, and everything. After a lot of frustration I found it the lesser of evils to just think in UTC regardless of where I am in the world, and convert for local people on the fly.
- lstodd 1y ago
  Let's hear why you think this.
  - Terr_ 1y ago
    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?

skissane 1y 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 1y 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 1y 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-moon-sighting https://www.cnn.com/2025/02/27/travel/ramadan-start-crescent...

andrewinardeer 1y 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.

deleted 1y ago
[deleted]
laurencerowe 1y 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 1y 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 1y 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 1y ago

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

MBCook 1y 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“.

Sophira 1y ago
This absolutely would happen. Most Americans I know refer to their timezone as EST/CST/MST/PST even after March.
- macintux 1y ago
  I’m currently working at one of the world’s largest consumer banks, and for a company that really should care about the accuracy of such things, I see “EST’ frequently all summer long.
  - gerikson 1y ago
    In my experience, Brits refer to their time as "GMT" whether or not DST is in effect.
    - Sophira 1y ago
      True; I should have said "most people refer to their local timezone in that way". (The reason I didn't was because at the time, I was referring to those specific timezones, not because I was picking on Americans.)

Aloisius 1y 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.

dheera 1y 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.

simonw 1y 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-timezones.jpg https://static.simonwillison.net/static/2024/google-calendar...

arccy 1y ago
isn't it at GMT-4 Eastern Time - New York?
- simonw 1y ago
  Here's the search results you get if you type "eastern" in that interface: https://gist.github.com/simonw/c2a73e40bbc87b8c25333207c551f7af?permalink_comment_id=5759017#gistcomment-5759017 https://gist.github.com/simonw/c2a73e40bbc87b8c25333207c551f... Typing "New York" gets zero results. Even knowing the exact name of the timezone I want I still can't find it in that UI!
  - arccy 1y ago
    At least for me, since it's ordered by offset, i just scroll to the approximate offset rather than try to type. On android, "eastern" similarly results in a mess of results (but eastern is a bad name anyway...), "new york" does find it.
  - yencabulator 1y ago
    The desktop web version seems to have no type-in search functionality. In the Android app typing "new y" gives Eastern Daylight Time 18:30 GMT-4 United States, *New Y*ork

jjmarr 1y 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#/media/File:Timezone-boundary-builder_release_2023d.png 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 1y 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 1y 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 1y 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.