Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Date
Msg-id 17148.1561568815@sss.pgh.pa.us
Whole thread Raw
In response to Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Thomas" == Thomas Munro <thomas.munro@gmail.com> writes:
>  Thomas> Right. On a FreeBSD system here in New Zealand you get "NZ"
>  Thomas> with default configure options (ie using PostgreSQL's tzdata).
>  Thomas> But if you build with --with-system-tzdata=/usr/share/zoneinfo
>  Thomas> you get "Pacific/Auckland", and that's because the FreeBSD
>  Thomas> zoneinfo directory doesn't include the old non-city names like
>  Thomas> "NZ", "GB", "Japan", "US/Eastern" etc.

> Same issue here with Europe/London getting "GB".

FreeBSD offers yet another obstacle to Andrew's proposal:

$ uname -a
FreeBSD rpi3.sss.pgh.pa.us 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  arm64
$ ls /usr/share/zoneinfo/
Africa/         Australia/      Etc/            MST             WET
America/        CET             Europe/         MST7MDT         posixrules
Antarctica/     CST6CDT         Factory         PST8PDT         zone.tab
Arctic/         EET             HST             Pacific/
Asia/           EST             Indian/         SystemV/
Atlantic/       EST5EDT         MET             UTC

No zone1970.tab.  I do not think we can rely on that file being there,
since zic itself doesn't install it; it's up to packagers whether or
where to install the "*.tab" files.

In general, the point I'm trying to make is that our policy should be
"Ties are broken arbitrarily, and if you don't like the choice that initdb
makes, here's how to fix it".  As soon as we try to break some ties in
favor of somebody's idea of what is "right", we are in for neverending
problems with different people disagreeing about what is "right", and
insisting that their preference should be the one the code enforces.
Let's *please* not go there, or even within hailing distance of it.

(By this light, even preferring UTC over UCT is a dangerous precedent.
I won't argue for reverting that, but I don't want to go further.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: mcvstats serialization code is still shy of a load
Next
From: Tom Lane
Date:
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)