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

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>, Christoph Berg <myon@debian.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-06-06T17:18:50Z
Lists: pgsql-hackers
Hi,

On 2019-06-06 12:51:30 -0400, Tom Lane wrote:
> [ sorry for slow response, I'm on vacation ]

Good.


> Andres Freund <andres@anarazel.de> writes:
> > That makes sense. As far as I can tell the reason that 12 sometimes ends
> > up with the proper timezone is that we shortcut the search by:
>
> > 	/*
> > 	 * Try to avoid the brute-force search by seeing if we can recognize the
> > 	 * system's timezone setting directly.
> > 	 *
> > 	 * Currently we just check /etc/localtime; there are other conventions for
> > 	 * this, but that seems to be the only one used on enough platforms to be
> > 	 * worth troubling over.
> > 	 */
> > 	if (check_system_link_file("/etc/localtime", &tt, resultbuf))
> > 		return resultbuf;
>
> > which is actually a behaviour changing, rather than just an
> > optimization, when there's a lot of equivalently scoring timezones.
>
> 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.

Note that on 11 I *do* end up with some *other* timezone with the newer
timezone data:

$cat /etc/timezone;ls -l /etc/localtime
Etc/UTC
lrwxrwxrwx 1 root root 27 Jun  6 17:02 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC

$ rm -rf /tmp/tztest;~/build/postgres/11-assert/install/bin/initdb /tmp/tztest 2>&1|grep -v 'scores 0'|grep -v 'uses leap seconds';grep timezone /tmp/tztest/postgresql.conf
...
TZ "Zulu" gets max score 5200
TZ "UCT" gets max score 5200
TZ "Universal" gets max score 5200
TZ "UTC" gets max score 5200
TZ "Etc/Zulu" gets max score 5200
TZ "Etc/UCT" gets max score 5200
TZ "Etc/Universal" gets max score 5200
TZ "Etc/UTC" gets max score 5200
TZ "localtime" gets max score 5200
TZ "posix/Zulu" gets max score 5200
TZ "posix/UCT" gets max score 5200
TZ "posix/Universal" gets max score 5200
TZ "posix/UTC" gets max score 5200
TZ "posix/Etc/Zulu" gets max score 5200
TZ "posix/Etc/UCT" gets max score 5200
TZ "posix/Etc/Universal" gets max score 5200
TZ "posix/Etc/UTC" gets max score 5200
ok
...

log_timezone = 'UCT'
timezone = 'UCT'
#timezone_abbreviations = 'Default'     # Select the set of available time zone
					# share/timezonesets/.

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. There you get:

TZ "Zulu" gets max score 5200
TZ "Universal" gets max score 5200
TZ "UTC" gets max score 5200
TZ "Etc/Zulu" gets max score 5200
TZ "Etc/Universal" gets max score 5200
TZ "Etc/UTC" gets max score 5200
ok

and end up with UTC as the selection.

I do think that < 12 clearly regressed here, although it's only exposing
previous behaviour further.

Greetings,

Andres Freund



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.