Date: Thu, 1 Aug 2019 10:19:51 -0700
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>
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release
 2019a.)
Message-ID: <20190801171951.pzpp5ywdn4pgqjzc@alap3.anarazel.de>
References: <2643.1561508327@sss.pgh.pa.us>
 <877e98syi5.fsf@news-spur.riddles.org.uk>
 <CA+hUKGLZN3XHqZPN08itV4W-Nu3ndZ9zKJGSvzoWLm6AU9vz-g@mail.gmail.com>
 <8736jwsdv2.fsf@news-spur.riddles.org.uk>
 <17148.1561568815@sss.pgh.pa.us>
 <87y31oq9g6.fsf@news-spur.riddles.org.uk>
 <CA+hUKGJniUoFuC8vPJBKbMWNwvZo_wGQ8gVAZFCS068Rei9dzQ@mail.gmail.com>
 <3961.1564086915@!sss.pgh.pa.us>
 <CADT4RqBkkWEXr7saiFhwSptuYBAEU_e_XZxRD3o7GCSuk++Y9A@mail.gmail.com>
 <5560.1564668481@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5560.1564668481@sss.pgh.pa.us>
Precedence: bulk

Hi,

On 2019-08-01 10:08:01 -0400, Tom Lane wrote:
> I have in fact committed that patch.  It won't do anything for your
> problem with respect to existing installations that may have picked
> "localtime", but it'll at least prevent new initdb runs from picking
> that.

>     Avoid choosing "localtime" or "posixrules" as TimeZone during initdb.
>     
>     Some platforms create a file named "localtime" in the system
>     timezone directory, making it a copy or link to the active time
>     zone file.  If Postgres is built with --with-system-tzdata, initdb
>     will see that file as an exact match to localtime(3)'s behavior,
>     and it may decide that "localtime" is the most preferred spelling of
>     the active zone.  That's a very bad choice though, because it's
>     neither informative, nor portable, nor stable if someone changes
>     the system timezone setting.  Extend the preference logic added by
>     commit e3846a00c so that we will prefer any other zone file that
>     matches localtime's behavior over "localtime".

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?

Greetings,

Andres Freund