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