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 1ht76D-0006O6-JW for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Aug 2019 09:10:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ht76C-0003Z8-Ec for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Aug 2019 09:10:12 +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 1ht76B-0003Rz-WC for pgsql-hackers@lists.postgresql.org; Thu, 01 Aug 2019 09:10:12 +0000 Received: from mail-lj1-x243.google.com ([2a00:1450:4864:20::243]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ht769-0006mX-Bl for pgsql-hackers@postgresql.org; Thu, 01 Aug 2019 09:10:11 +0000 Received: by mail-lj1-x243.google.com with SMTP id z28so14382032ljn.4 for ; Thu, 01 Aug 2019 02:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=roji.org; s=roji; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AnxVJfLTKnEvwpzZXnm7WlxOBwT36lrJEcYFyizep/c=; b=Vv+1TVhouJDZqmQ3g6ydp2yz1riqxyXvJI50gxVaWk9xUm8khYm+YLcyAdK64yooqp xCk65itH7g/l6yvoDjb05FCyJ6SC0yF4iNoPrktY1B2B6UpbIlJvb6jWnjkmyWmnHFmS FWd0v+lB7e//mQNr/Y5Wa3ULYFoOY1pQza20I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AnxVJfLTKnEvwpzZXnm7WlxOBwT36lrJEcYFyizep/c=; b=AU6AvD5me74l+ooXWvf3X+rNu1c07eyBANdRsh5DJGUo/e0ngNJxuqmOQzHFLcWFKe x6r86P3+ynMlHoR2IG+oTcm1ROyWkuTsTUWfHK62/XYoMUva4ll13CRC7wlC7IrEoXs/ joV6SvWU2dP9rYd4gSgLYZhVz8rz3RU3YlWU/cz++pE79Vg1rn9XC+eV1pW6Hi44K8+l PPjeQNMfn2jKW/JBa6aVXAdyTV4dw7SngEFWXYQvMU1kCHe76/vvyC0h2g9KX0PL/ZkB idrIRuBkmGimBAHJmby5PD/TgMhSLUNA3Yx+uEVr8KQgWjRR09xaC+gwcunmE5aOgGJn 23Kg== X-Gm-Message-State: APjAAAWniGgHpPp2g5UsY8R2bX7cuiHMIniq74+eBOALcGQDtjdouO5y FmmZroSW1PJhldE8gPDWT0gYiHnCW6G3aHa6SjQ= X-Google-Smtp-Source: APXvYqwsrJTb2O8/PFHMvZZZ6aMuZTaJQuhYyVSOVfhNM06bzT0hftm4jTB2qBOFamHonygcVS1iUi4ARm65dLMj3pA= X-Received: by 2002:a2e:298a:: with SMTP id p10mr65937488ljp.74.1564650605672; Thu, 01 Aug 2019 02:10:05 -0700 (PDT) MIME-Version: 1.0 References: <24452.1560285699@sss.pgh.pa.us> <20190614095546.GA15107@msg.df7cb.de> <26948.1560517875@sss.pgh.pa.us> <87ef3w3u8a.fsf@news-spur.riddles.org.uk> <7114.1560539536@sss.pgh.pa.us> <875zp74zpf.fsf@news-spur.riddles.org.uk> <871rzv4yes.fsf@news-spur.riddles.org.uk> <20190617173943.z3ttxqenbcwrlag4@alap3.anarazel.de> <20190617183458.GG2480@tamriel.snowman.net> <20190617183828.hj7ci362zbxd4nax@alap3.anarazel.de> <20190617184053.GI2480@tamriel.snowman.net> <25314.1560980148@sss.pgh.pa.us> <27991.1560984458@sss.pgh.pa.us> <877e9h18df.fsf@news-spur.riddles.org.uk> <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> In-Reply-To: <3961.1564086915@sss.pgh.pa.us> From: Shay Rojansky Date: Thu, 1 Aug 2019 11:09:54 +0200 Message-ID: Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.) To: Tom Lane Cc: Thomas Munro , Andrew Gierth , Robert Haas , Stephen Frost , Andres Freund , Christoph Berg , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="0000000000008c9832058f0a9b27" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000008c9832058f0a9b27 Content-Type: text/plain; charset="UTF-8" > I'm not sure we're any closer to a meeting of the minds on whether > consulting zone[1970].tab is a good thing to do, but we got an actual > user complaint[1] about how "localtime" should not be a preferred > spelling. So I want to go ahead and insert the discussed anti-preference > against "localtime" and "posixrules", as per 0001 below. If we do do > something with zone[1970].tab, we'd still need these special rules, > so I don't think this is blocking anything. Just want to stress this point from a PostgreSQL driver maintainer perspective (see here[1] for the full details). Having "localtime" as the PostgreSQL timezone basically means that the timezone is completely opaque from a client point of view - there is no way for clients to know what actual timezone the server is in, and react to that. This is a limiting factor in client development, I hope a consensus on this specific point can be reached. [1] https://www.postgresql.org/message-id/CADT4RqCCnj6FKLisvT8tTPfTP4azPhhDFJqDF1JfBbOH5w4oyQ@mail.gmail.com --0000000000008c9832058f0a9b27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I'm not sure we're any closer to a meeti= ng of the minds on whether
> consulting zone[1970].tab is a go= od thing to do, but we got an actual
> user complaint[1] about= how "localtime" should not be a preferred
> spellin= g.=C2=A0 So I want to go ahead and insert the discussed anti-preference
> against "localtime" and "posixrules", as pe= r 0001 below.=C2=A0 If we do do
> something with zone[1970].ta= b, we'd still need these special rules,
> so I don't t= hink this is blocking anything.

Just want to stres= s this point from a PostgreSQL driver maintainer perspective (see here[1] f= or the full details). Having "localtime" as the PostgreSQL timezo= ne basically means that the timezone is completely opaque from a client poi= nt of view - there is no way for clients to know what actual timezone the s= erver is in, and react to that. This is a limiting factor in client develop= ment, I hope a consensus on this specific point can be reached.

--0000000000008c9832058f0a9b27--