Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tf0AH-00GsN5-H2 for pgsql-docs@arkaria.postgresql.org; Mon, 03 Feb 2025 17:23:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tf0AE-00FREQ-Sj for pgsql-docs@arkaria.postgresql.org; Mon, 03 Feb 2025 17:23:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tf0AE-00FREI-La for pgsql-docs@lists.postgresql.org; Mon, 03 Feb 2025 17:23:14 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tf0AC-002ykU-11 for pgsql-docs@lists.postgresql.org; Mon, 03 Feb 2025 17:23:13 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 513HN7Do410527; Mon, 3 Feb 2025 12:23:07 -0500 From: Tom Lane To: =?utf-8?Q?=C3=81lvaro?= Herrera cc: Robert Treat , Laurenz Albe , bristleconeweb@gmail.com, pgsql-docs@lists.postgresql.org Subject: Re: timestamp with time zone ~> GMT In-reply-to: <202502031621.j4h5q2bp3orj@alvherre.pgsql> References: <202502031621.j4h5q2bp3orj@alvherre.pgsql> Comments: In-reply-to =?utf-8?Q?=C3=81lvaro?= Herrera message dated "Mon, 03 Feb 2025 17:21:41 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <410525.1738603387.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 03 Feb 2025 12:23:07 -0500 Message-ID: <410526.1738603387@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk =3D?utf-8?Q?=3DC3=3D81lvaro?=3D Herrera writes: > On 2025-Feb-03, Robert Treat wrote: >> This does seem to come up often enough that it probably is worth being >> a bit more explicit about how this works; attached patch attempts >> that. > LGTM. Hmm, I kind of like the up-front statement that timestamptz stores UTC. How about this simpler change? diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index 1d9127e94e..269809dc81 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -2263,6 +2263,8 @@ TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02' then it is assumed to be in the time zone indicated by the system's parameter, and is converted to UTC= using the offset for the timezone zone. + In either case, the originally stated or assumed time zone is not + retained. = >> Note, I dropped the bit about GMT; that change was made ~40 years ago, >> and I suspect it is close to noise for many people these days, though >> it could be added back if folks feel strongly about it. > I don't feel strongly about it, but another option might be to add a > so that it is still there but less intrusive. Grepping for > GMT in the postgres repo there are still over 1400 matches of all kinds. I think we'd better not remove the gloss for GMT just yet. It's still the magic boot value for the timezone GUC for example (cf pgtz.c), and it's still embedded in the IANA timezone database: $ ls /usr/share/zoneinfo/Etc GMT GMT+11 GMT+4 GMT+8 GMT-10 GMT-14 GMT-5 GMT-9 UTC GMT+0 GMT+12 GMT+5 GMT+9 GMT-11 GMT-2 GMT-6 GMT0 Universal GMT+1 GMT+2 GMT+6 GMT-0 GMT-12 GMT-3 GMT-7 Greenwich Zulu GMT+10 GMT+3 GMT+7 GMT-1 GMT-13 GMT-4 GMT-8 UCT Maybe we could move the info to the Glossary, but that seems like a separate matter from what's under discussion here. regards, tom lane