Comment by jjmarr
2 days 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.
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.
> 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).