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