Horton

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>, Christoph Berg <myon@debian.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-06-06T17:44:54Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2019-06-06 12:51:30 -0400, Tom Lane wrote:
>> Sure, that is intentionally a behavior change in this situation.
>> The theory is that if "Etc/UCT" is what the user put in /etc/localtime,
>> then that's the spelling she wants.  See 23bd3cec6.

> Right, I'm not complaining about that. I'm just noting that that
> explains the cross-version divergence.

It explains some cross-version divergence for sure.  What I'm still not
clear about is whether Christoph's report is entirely that, or whether
there's some additional factor we don't understand yet.

> As you can see the switch from Etc/UTC to UCT does happen here
> (presumably in any branch before 12). Which did not happen before the
> import of 2019a / when using a system tzdata that's before
> that.

Right.  Before 2019a, UCT would not have been a match to a system
setting of UTC because the zone abbreviation reported by localtime()
was different.  Now it's the same abbreviation.

Maybe we should consider back-patching 23bd3cec6.

			regards, tom lane

Commits

  1. Tweak our special-case logic for the IANA "Factory" timezone.

  2. Avoid choosing "localtime" or "posixrules" as TimeZone during initdb.

  3. Prefer timezone name "UTC" over alternative spellings.

  4. Attempt to identify system timezone by reading /etc/localtime symlink.

  5. Update time zone data files to tzdata release 2019a.