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

Is there a problem with ISO3166 denoted information in general or is there a specific US issue here? I would think ISO code denoted tzdata was a public good in some sense.

You can see the zones that are deprecated at https://packages.debian.org/sid/all/tzdata-legacy/filelist

All the legacy time zones were moved out of the default zoneinfo install. It’s not a us-specific issue but the legacy US/ timezones remain in widespread use, and they stop working on Debian 13 ootb (possibly Ubuntu noble as well?).

Are they in widespread use? They were deprecated in 1995.

I don't see conflict in those statements.

Does anyone know why they are still in widespread use?

Config defaults somewhere still using them? Man page examples? Tutorials using them? Or just force of habit?

This has nothing to do with ISO 3166 at all. The tzdata database is the work of a single person, Arthur Olson, not a committee (or rather it was, from its birth in the 1980s until 2011 when a company decided to sue him for no reason).

And for most of its life it’s been an explicit policy that timezones are named by continent and representative population center, not by country, to avoid entangling it in territorial disputes and improve naming stability for historical data. The US/* (and Canada/*, etc.) names are deprecated and have been since 1995 (?), but apparently people were still using them because the deprecation wasn’t really apparent unless one was especially into reading release notes.

Some of this is surely just muscle memory or intertia as well. I remember random config values from when I was trying out linux boxes back in high school that I replicated into files that just don't get touched for decades afterwards.

When was the last time you rebuilt your company's postgres config from scratch?

Interesting, I hadn't heard about that frivolous lawsuit before: https://www.eff.org/press/releases/eff-wins-protection-time-...

> Does anyone know why they are still in widespread use?

Because of a lack of things compelling people to change them until it causes a breakage. And then when it does cause a breakage, most people would rather move heaven and earth to complain, research workarounds, etc. rather than just change it. (Institutional structures can also make "just" changing it far harder than that should be.)

I suspect some of it will be because the legacy form is a bit more intuitive than the standard form. You don’t really use continents and cities as a reference to time zones normally, countries and local subdivisions makes more sense, but as other people note, it brings up POLITICS.

You don't use them normally in the US, I've been referring to europe/amsterdam or europe/paris all my life in Linux installers and various equipment. I've never ever encountered netherlands/amsterdam or something like that.

I wonder how much of an influence it is that US/Eastern is easier to type than America/New_York

> When was the last time you rebuilt your company's postgres config from scratch?

Last year, when we upgrade to version 17.

I looked at the example/template configuration, diffed it with our configuration from PG15, and for every change decided whether to keep our version or the new setting.

I didn't use it, but Debian/APT has had a tool to do this sort of comparison for any software upgrade for as long as I can remember.

Do other people just copy the old config and shout "YOLO!"?

There’s definitely inertia but I think it’s also that the US/ names match official usage: nobody, not even residents, says the time zone is New York because the official name is Eastern time.

Still typing "nano -w filename" each and every time since back around y2k when I was working on Linux for the first time I was told that bad things could happen if I didn't...

From the list of deprecated zones, we could have been using "GB", "Poland", "Portugal", "CET", but that's about it. "Netherlands" didn't exist.

Given the old names were deprecated in 1993, it's hardly surprising that I never before discovered "GB".

Exactly this. I still don't know if there's a technical difference between America/New_York, America/Detroit, or America/Indianapolis.

America/Detroit is different from America/New_York on times before 1915 (when Detroit switched from Central to Eastern Time).

It’s the same in Europe as it is in the US. Normal people refer to Europe/Paris as CET, just like normal people refer to America/New_York as Eastern Time.

When your configuration value from PG15 was different from the old default and the new default on something like the statement timeout, and the statement timeout was previously working fine, and obstensibly set for a reason.... I dunno, are you going to question the value that much?

And you might say "well I know how a statement timeout works" and I agree! I would also generally agree that something like a timezone setting would generally be something I'd expect to be fairly stable.

That's what I meant about rebuilding the config from scratch. Rebuilding from scratch would almost involve _not even looking at the existing configuration_ and then doing first principles footwork to figure out what is needed.

I think the diffing flow you went through is the right way to do it, but I believe that flow might lead to some values getting less scrutiny than others. Still perfectly reasonable though