Re: UCT (Re: pgsql: Update time zone data files to tzdata release2019a.) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: UCT (Re: pgsql: Update time zone data files to tzdata release2019a.)
Date
Msg-id 20190801171951.pzpp5ywdn4pgqjzc@alap3.anarazel.de
Whole thread Raw
In response to Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: using explicit_bzero
Next
From: Robert Haas
Date:
Subject: Re: progress report for ANALYZE