MIME-Version: 1.0
References: <CAEfWYyzvM4XcfKunhvT1_xs_9rGnbXbRvnn_znQD4-Wg-aA5Vg@mail.gmail.com>
 <fd3ad9cc-50da-47a4-8177-3915ad7186bf@aklaver.com> <2e2a34695d84a297e62a2996466fecf97005a2fb.camel@cybertec.at>
 <2555134.1763772908@sss.pgh.pa.us>
In-Reply-To: <2555134.1763772908@sss.pgh.pa.us>
From: Steve Crawford <scrawford@pinpointresearch.com>
Date: Mon, 24 Nov 2025 11:43:07 -0800
Message-ID: <CAEfWYyyBCRD-0fY=+nMUUmgqhqPsDyy1NWjc2bP1Mb_yPpV4iA@mail.gmail.com>
Subject: Re: Unexpected date conversion results
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, Adrian Klaver <adrian.klaver@aklaver.com>, 
	PG-General Mailing List <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000000b65c706445c60fd"
Archived-At: <https://www.postgresql.org/message-id/CAEfWYyyBCRD-0fY%3D%2BnMUUmgqhqPsDyy1NWjc2bP1Mb_yPpV4iA%40mail.gmail.com>
Precedence: bulk

--0000000000000b65c706445c60fd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 21, 2025 at 4:55=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Laurenz Albe <laurenz.albe@cybertec.at> writes:
> > I dug into the git history, and it has been like that since commit
> b3506006b564
> > in 2002 (way before version 9.x).  That commit fixed a bug that returne=
d
> ten
> > time the correct reault (but still offset from the UTC epoch).
>
> I didn't bisect, but I get this in 9.1.24:
>
> regression=3D# set timezone =3D 'America/Los_Angeles';
> SET
> regression=3D# select to_timestamp(extract(epoch from current_date));
>       to_timestamp
> ------------------------
>  2025-11-21 00:00:00-08
> (1 row)
>
> and this in 9.2.24:
>
> regression=3D# set timezone =3D 'America/Los_Angeles';
> SET
> regression=3D# select to_timestamp(extract(epoch from current_date));
>       to_timestamp
> ------------------------
>  2025-11-20 16:00:00-08
> (1 row)
>
>                         regards, tom lane
>

I guess this reveals the age of the bit of code I was resurrecting, he says
while pulling out his Pg 8.4 release t-shirt. :)

After much more digging I found the relevant remark way back in the 9.2
release notes (https://www.postgresql.org/docs/release/9.2.0/):

Make EXTRACT(EPOCH FROM timestamp without time zone) measure the epoch from
local midnight, not UTC midnight (Tom Lane)


This change reverts an ill-considered change made in release 7.3. Measuring
from UTC midnight was inconsistent because it made the result dependent on
the timezone setting, which computations for timestamp without time zone
should not be. The previous behavior remains available by casting the input
value to timestamp with time zone.

Sorry for the goose chase.

-Steve

--0000000000000b65c706445c60fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"></div><br><div class=3D"gmail_quote gmail=
_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 21, 202=
5 at 4:55=E2=80=AFPM Tom Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl@=
sss.pgh.pa.us</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">Laurenz Albe &lt;<a href=3D"mailto:laurenz.albe@cybertec.at" t=
arget=3D"_blank">laurenz.albe@cybertec.at</a>&gt; writes:<br>
&gt; I dug into the git history, and it has been like that since commit b35=
06006b564<br>
&gt; in 2002 (way before version 9.x).=C2=A0 That commit fixed a bug that r=
eturned ten<br>
&gt; time the correct reault (but still offset from the UTC epoch).<br>
<br>
I didn&#39;t bisect, but I get this in 9.1.24:<br>
<br>
regression=3D# set timezone =3D &#39;America/Los_Angeles&#39;;<br>
SET<br>
regression=3D# select to_timestamp(extract(epoch from current_date));<br>
=C2=A0 =C2=A0 =C2=A0 to_timestamp=C2=A0 =C2=A0 =C2=A0 <br>
------------------------<br>
=C2=A02025-11-21 00:00:00-08<br>
(1 row)<br>
<br>
and this in 9.2.24:<br>
<br>
regression=3D# set timezone =3D &#39;America/Los_Angeles&#39;;<br>
SET<br>
regression=3D# select to_timestamp(extract(epoch from current_date));<br>
=C2=A0 =C2=A0 =C2=A0 to_timestamp=C2=A0 =C2=A0 =C2=A0 <br>
------------------------<br>
=C2=A02025-11-20 16:00:00-08<br>
(1 row)<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 regards, tom lane<br></blockquote><div><br></div><div>I guess th=
is reveals the age of the bit of code I was resurrecting, he says while pul=
ling out his Pg 8.4 release t-shirt. :)=C2=A0</div><div><br></div><div>Afte=
r much more digging I found the relevant remark way back in the 9.2 release=
 notes (<a href=3D"https://www.postgresql.org/docs/release/9.2.0/">https://=
www.postgresql.org/docs/release/9.2.0/</a>):</div><div><br></div></div><blo=
ckquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div class=3D"g=
mail_quote gmail_quote_container"><div>Make EXTRACT(EPOCH FROM timestamp wi=
thout time zone) measure the epoch from local midnight, not UTC midnight (T=
om Lane)</div></div></blockquote><div class=3D"gmail_quote gmail_quote_cont=
ainer"><div><br></div></div><blockquote style=3D"margin:0 0 0 40px;border:n=
one;padding:0px"><div class=3D"gmail_quote gmail_quote_container"><div>This=
 change reverts an ill-considered change made in release 7.3. Measuring fro=
m UTC midnight was inconsistent because it made the result dependent on the=
 timezone setting, which computations for timestamp without time zone shoul=
d not be. The previous behavior remains available by casting the input valu=
e to timestamp with time zone.</div><div><br></div></div></blockquote><div>=
Sorry for the goose chase.</div><div><br></div>-Steve<br><div><div class=3D=
"gmail_quote gmail_quote_container"><div><br></div></div></div></div>

--0000000000000b65c706445c60fd--