Horton

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

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Shay Rojansky <roji@roji.org>, Thomas Munro <thomas.munro@gmail.com>, Andrew Gierth <andrew@tao11.riddles.org.uk>, Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, Christoph Berg <myon@debian.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-08-01T18:25:23Z
Lists: pgsql-hackers 
Hi,

On 2019-08-01 13:59:11 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > When used and a symlink, could we resolve the symlink when determining
> > the timezone? When loading a timezone in the backend, not during
> > initdb. While that'd leave us with the instability, it'd at least would
> > help clients etc understand what the setting actually means?
> 
> The question here is what the string "localtime" means when it's in
> the timezone variable.

Right.


> I guess yes, we could install some show_hook for timezone that goes
> and looks to see if it can resolve what that means.  But that sure
> seems to me to be in you've-got-to-be-kidding territory.

Fair enough. I'm mildly worried that people will just carry their
timezone setting from one version's postgresql.conf to the next as they
upgrade.


> Especially since the platforms I've seen that do this tend to use hard
> links, so that it's questionable whether the pushups would accomplish
> anything at all.

Hm, debian's is a symlink (or rather a chain of):

$ ls -l /usr/share/zoneinfo/localtime
lrwxrwxrwx 1 root root 14 Jul  4 14:04 /usr/share/zoneinfo/localtime -> /etc/localtime

$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 39 Jul 15 15:40 /etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles

The system installed versions of postgres I have available all ended up
with timezone=localtime.

Not sure how long they've been symlinks. I randomly accessed a backup of
an older debian installation, from 2014, and there it's a file (with
link count 1).

But presumably upgrading would yield a postgresql.conf that still had
localtime, but localtime becoming a symlink.

Greetings,

Andres Freund

Commits

  1. Tweak our special-case logic for the IANA "Factory" timezone.

  2. Avoid choosing "localtime" or "posixrules" as TimeZone during initdb.

  3. Prefer timezone name "UTC" over alternative spellings.

  4. Attempt to identify system timezone by reading /etc/localtime symlink.

  5. Update time zone data files to tzdata release 2019a.