Recreating the US/* time zone situation

Re:Recreating the US/* time zone situation by Aloisius on Sunday September 14, 2025 @12:42AM (#45237495)

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

[ Parent | on HN ]

Re:Recreating the US/* time zone situation by dheera on Sunday September 14, 2025 @10:18AM (#45239896)

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.

[ Parent | on HN ]