Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1htFMO-0004ny-Hi for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Aug 2019 17:59:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1htFMM-0008WV-JE for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Aug 2019 17:59:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1htFMM-0008WO-AU for pgsql-hackers@lists.postgresql.org; Thu, 01 Aug 2019 17:59:26 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1htFMJ-0003y2-HD for pgsql-hackers@postgresql.org; Thu, 01 Aug 2019 17:59:25 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x71HxBW1008332; Thu, 1 Aug 2019 13:59:11 -0400 From: Tom Lane To: Andres Freund cc: Shay Rojansky , Thomas Munro , Andrew Gierth , Robert Haas , Stephen Frost , Christoph Berg , PostgreSQL Hackers Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.) In-reply-to: <20190801171951.pzpp5ywdn4pgqjzc@alap3.anarazel.de> References: <2643.1561508327@sss.pgh.pa.us> <877e98syi5.fsf@news-spur.riddles.org.uk> <8736jwsdv2.fsf@news-spur.riddles.org.uk> <17148.1561568815@sss.pgh.pa.us> <87y31oq9g6.fsf@news-spur.riddles.org.uk> <3961.1564086915@!sss.pgh.pa.us> <5560.1564668481@sss.pgh.pa.us> <20190801171951.pzpp5ywdn4pgqjzc@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Thu, 01 Aug 2019 10:19:51 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8330.1564682351.1@sss.pgh.pa.us> Date: Thu, 01 Aug 2019 13:59:11 -0400 Message-ID: <8331.1564682351@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andres Freund writes: > When used and a symlink, could we resolve the symlink when determining > the timezone? When loading a timezone in the backend, not during > initdb. While that'd leave us with the instability, it'd at least would > help clients etc understand what the setting actually means? The question here is what the string "localtime" means when it's in the timezone variable. I guess yes, we could install some show_hook for timezone that goes and looks to see if it can resolve what that means. But that sure seems to me to be in you've-got-to-be-kidding territory. Especially since the platforms I've seen that do this tend to use hard links, so that it's questionable whether the pushups would accomplish anything at all. regards, tom lane