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

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

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.

FWIW if Boston switches, it won’t be America/Puerto_Rico, it’ll get a new zone name (probably America/Boston). Tzdb zones express that everywhere in that zone has always been on the same time, since the advent of standard timekeeping, so they always fracture when some subset moves to a different zone.

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)

> the folks who run the tz db definitely know what they're doing

It's one guy. He demonstrably does NOT know what he's doing.

> I always prefer `US/Eastern`

As you should. It's the actual name of the timezone as published by the entity that defines it. Outside of the goofy definitions in the tz file it's what everyone living _inside_ of that timezone would call it and see it referenced as.

To call this "backwards" is an absolute insult to civil time keeping and drives me insane.

> doesn't that make more sense?

I always thought it should be served through DNS. Then each country can just define it's own TZ record type and embed it at the root of their country code domain and could expand on it however they like.

eastern.timezone.us

Also, since domain names have punycode for internationalization, you could actually call timezones in countries like Mexico what they're actually named for end users.

This is a fantastic idea.

You could use this to promulgate SRV records that direct you to a country’s authoritative time servers, too.