Re: here does postgres take its timezone information from?

> 16 nov. 2019 kl. 23:06 skrev Thomas Munro <thomas(dot)munro(at)gmail(dot)com>:
>
> On Sat, Nov 16, 2019 at 7:13 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>> Palle Girgensohn <girgen(at)pingpong(dot)net> writes:
>>> 15 nov. 2019 kl. 21:32 skrev Thomas Munro <thomas(dot)munro(at)gmail(dot)com>:
>>>> Ugh. It doesn't have the old backward compatibility names like
>>>> US/Pacific installed by default, which is a problem if that's what
>>>> initdb picked for your cluster (or you've stored references to any of
>>>> those names in other ways).
>>
>>> One quick fix is to revert the change. Tom thinks this is not reason to revert. Would it be enough to edit the postgresql.conf to use the correct "modern" name for US/Pacific (PST?)? In rhar case, an update note might be sufficient?
>>
>> I think the "official" name of that zone is America/Los_Angeles.
>> But initdb might seize on the US/Pacific alias, if available,
>> because it's shorter. We've seen related problems with other
>> time zone names, though usually it was just cosmetic and not a
>> reason for the postmaster to fail to start.
>>
>> Yes, changing the zone name in postgresql.conf should be a sufficient
>> fix. In theory, a FreeBSD user ought to know the "official" alias
>> for their zone, since the rest of the system would expect that.
>> So this is slightly tedious if initdb chose a non-official alias,
>> but I don't think it's reason to panic.
>
> Perhaps the best thing would be to revert this for the older
> PostgreSQL releases so that people doing minor version upgrades are
> inconvenienced by a system that can't start up after "pkg upgrade",
> but do it for 12 since not many people will be using that yet?

That could be a way, yes. Any thoughts on this from others following this thread?

Palle