Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
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-01T17:59:11Z
Lists: pgsql-hackers 
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.

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

			regards, tom lane

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.