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


Reply via email to