Date: Tue, 4 Jun 2019 16:44:57 +0000
From: Andres Freund <andres@anarazel.de>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Christoph Berg <myon@debian.org>, Tom Lane <tgl@sss.pgh.pa.us>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release
 2019a.)
Message-ID: <20190604164457.772invck3lgxk75s@alap3.anarazel.de>
References: <E1hK8qL-0005yH-VX@gemulon.postgresql.org>
 <20190604085735.GD24018@msg.df7cb.de>
 <87ftop8gtr.fsf@news-spur.riddles.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87ftop8gtr.fsf@news-spur.riddles.org.uk>
Precedence: bulk

Hi,

On 2019-06-04 17:20:42 +0100, Andrew Gierth wrote:
> fwiw on FreeBSD with no /etc/localtime and no TZ in the environment (and
> hence running on UTC), I get "UCT" on both 11.3 and HEAD.

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.

Greetings,

Andres Freund