Date: Thu, 7 Sep 2023 17:00:59 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: davecramer@postgres.rocks, pgsql-docs@lists.postgresql.org
Subject: Re: Incorrect/confusing information about timetz
Message-ID: <ZPo6C2s9PDAwfKeS@momjian.us>
References: <168451942371.714.9173574930845904336@wrigleys.postgresql.org>
 <ZPozoUwxa80aarQp@momjian.us>
 <1757505.1694119308@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BTzFmqq6IAaEb9pX"
Content-Disposition: inline
In-Reply-To: <1757505.1694119308@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/ZPo6C2s9PDAwfKeS%40momjian.us>
Precedence: bulk


--BTzFmqq6IAaEb9pX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Sep  7, 2023 at 04:41:48PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Uh, yes to the storage part, no to the output part.  ;-)  Postgres does
> > store the timetz time zone offset, but it doesn't adust it once it is
> > stored so doesn't adjust for the session time zone:
> 
> Right, it just stores a numeric UTC offset.
> 
> > Do we want to document this?
> 
> Section 8.5.1.2. Times already says "The appropriate time zone offset
> is recorded in the time with time zone value."  Maybe that could be
> made a little more precise, say "The resolved numeric offset from UTC
> is recorded in the time with time zone value."

Yeah, there is no mention of it odd output behavior.  Here is a patch to
add that.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

--BTzFmqq6IAaEb9pX
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="timetz.diff"

diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 8d32a8c9c5..240d4875d2 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -2040,7 +2040,8 @@ MINUTE TO SECOND
       <literal>America/New_York</literal>. In this case specifying the date
       is required in order to determine whether standard or daylight-savings
       time applies.  The appropriate time zone offset is recorded in the
-      <type>time with time zone</type> value.
+      <type>time with time zone</type> value and is output as stored; 
+      it is not adjusted to the active time zone.
      </para>
 
       <table id="datatype-datetime-time-table">

--BTzFmqq6IAaEb9pX--