Re: Unexpected date conversion results - Mailing list pgsql-general

From Steve Crawford
Subject Re: Unexpected date conversion results
Date
Msg-id CAEfWYyyBCRD-0fY=+nMUUmgqhqPsDyy1NWjc2bP1Mb_yPpV4iA@mail.gmail.com
Whole thread Raw
In response to Re: Unexpected date conversion results  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general

On Fri, Nov 21, 2025 at 4:55 PM 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 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

pgsql-general by date:

Previous
From: Nico Williams
Date:
Subject: Re: set role command
Next
From: Tom Lane
Date:
Subject: Re: set role command