←back to thread

Debian 13, Postgres, and the US/* time zones

(rachelbythebay.com)
283 points move-on-by | 1 comments | 12 Sep 25 02:33 UTC | HN request time: 0s | source
Show context
nja ◴[12 Sep 25 14:10 UTC] No.45222350[source]▶
I'm still not totally sure why these names were deprecated in the first place...

I mean, the folks who run the tz db definitely know what they're doing, it just never 100% clicked with my thinking.

I always prefer `US/Eastern` over `America/New_York` -- it seems more "canonical" to me. New York is _currently_ the anchor city for ET, but will it always be? The place I live (Boston) is currently on ET, but in the future it might be on Atlantic Time. If there was an `America/Boston`, I would use that to be safe, but since there isn't, it just seems better to be to be specific that I mean "Eastern Time" and not "whatever the time is in NYC"... At least then if Boston switches to a different tz, I could intentionally switch to "Atlantic Time" -- doesn't that make more sense? Versus I guess what I'd have to do, which is switch to `America/Puerto_Rico`? (I had to actually search that one, too bad there's no `US/Atlantic`...)

replies(3): >>45222679 #>>45222982 #>>45224650 #
skydhash ◴[12 Sep 25 14:42 UTC] No.45222679[source]▶
If New-York shifts its timezone, then it will still be New-York and America. And the new tzdata will reflect that shift so your data will always be correct (as in reflecting the time it is in new york). For local time, you will switch to a new city and the date will still be correct.
replies(1): >>45222999 #
1. nja ◴[12 Sep 25 15:12 UTC] No.45222999[source]▶
Exactly, but that is my point: usually my data is not intended to reflect the time it is in New York. Being tied to a (semi-)arbitrary city changes the actual meaning of the zone slightly. If every city was represented and I could choose "Boston" then that would make sense (for data is intended to reflect the time it is in Boston) but of course that's not entirely practical.

(I'll note that I agree with the general wisdom to store data in UTC; here when I talk about zones I'm either talking about user local machine time or display)