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>
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release
 2019a.)
In-reply-to: <20190604164457.772invck3lgxk75s@alap3.anarazel.de>
References: <E1hK8qL-0005yH-VX@gemulon.postgresql.org>
 <20190604085735.GD24018@msg.df7cb.de>
 <87ftop8gtr.fsf@news-spur.riddles.org.uk>
 <20190604164457.772invck3lgxk75s@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 04 Jun 2019 16:44:57 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <5518.1559839890.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 06 Jun 2019 12:51:30 -0400
Message-ID: <5519.1559839890@sss.pgh.pa.us>
Precedence: bulk

[ sorry for slow response, I'm on vacation ]

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 th=
e
> 	 * 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.

But it seems to me that this code is *not* determining the result in
Christoph's case, because if it were, it'd be settling on Etc/UTC,
according to his followup report that

>> lrwxrwxrwx 1 root root 27 M=C3=A4r 28 14:49 /etc/localtime -> /usr/shar=
e/zoneinfo/Etc/UTC

I'm not too familiar with what actually determines glibc's behavior
on Debian, but I'm suspicious that there's an inconsistency between
/etc/localtime and /etc/timezone.  We won't adopt the spelling we
see in /etc/localtime unless it agrees with the observed behavior of
localtime(3).

			regards, tom lane