public inbox for [email protected]
help / color / mirror / Atom feedFrom: Steve Crawford <[email protected]>
To: Tom Lane <[email protected]>
Cc: Laurenz Albe <[email protected]>
Cc: Adrian Klaver <[email protected]>
Cc: PG-General Mailing List <[email protected]>
Subject: Re: Unexpected date conversion results
Date: Mon, 24 Nov 2025 11:43:07 -0800
Message-ID: <CAEfWYyyBCRD-0fY=+nMUUmgqhqPsDyy1NWjc2bP1Mb_yPpV4iA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAEfWYyzvM4XcfKunhvT1_xs_9rGnbXbRvnn_znQD4-Wg-aA5Vg@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
On Fri, Nov 21, 2025 at 4:55 PM Tom Lane <[email protected]> wrote:
> Laurenz Albe <[email protected]> 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 returned
> 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=# set timezone = 'America/Los_Angeles';
> SET
> regression=# 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=# set timezone = 'America/Los_Angeles';
> SET
> regression=# 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
view thread (5+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Unexpected date conversion results
In-Reply-To: <CAEfWYyyBCRD-0fY=+nMUUmgqhqPsDyy1NWjc2bP1Mb_yPpV4iA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox