public inbox for [email protected]help / color / mirror / Atom feed
Re: Unexpected date conversion results 5+ messages / 4 participants [nested] [flat]
* Re: Unexpected date conversion results @ 2025-11-22 00:38 Adrian Klaver <[email protected]> 0 siblings, 2 replies; 5+ messages in thread From: Adrian Klaver @ 2025-11-22 00:38 UTC (permalink / raw) To: Steve Crawford <[email protected]>; pgsql-general On 11/21/25 16:09, Steve Crawford wrote: > Either there is a bug in my understanding or one in PostgreSQL. I expect > a date value to follow the current time zone setting and be interpreted > as midnight at the start of the given date. In many cases it does. Shown > below are the postgresql.conf settings and the psql client settings > showing the time zone to be America/Los_Angeles: > > postgresql.conf: > log_timezone = 'America/Los_Angeles' > timezone = 'America/Los_Angeles' > > Client time zone setting: > > steve=> show timezone; > TimeZone > --------------------- > America/Los_Angeles > > > However, extracting the epoch from current_date returns 4pm the prior > day (i.e. 2025-11-21 00:00:00-00), in other words midnight 2025-11-21 > UTC which seems to be inconsistent behavior: https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT "epoch For timestamp with time zone values, the number of seconds since 1970-01-01 00:00:00 UTC (negative for timestamps before that); for date and timestamp values, the nominal number of seconds since 1970-01-01 00:00:00, without regard to timezone or daylight-savings rules; for interval values, the total number of seconds in the interval " So epoch is in UTC which is confirmed by below. > > steve=> select to_timestamp(extract(epoch from current_date)); > to_timestamp > ------------------------ > 2025-11-20 16:00:00-08 If you want it to work(I am in 'America/Los_Angeles' also): select to_timestamp(extract(epoch from current_date)) at time zone 'UTC'; timezone --------------------- 2025-11-21 00:00:00 > There was a time, like version 9-dot-something, when the above queries > performed as expected returning midnight in the current time zone but I > haven't been able to find a change document indicating this as an > expected change. I don't remember that, but as the gray content of the hair increases the memory is less solid:) > > -Steve -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Unexpected date conversion results @ 2025-11-22 00:43 Laurenz Albe <[email protected]> parent: Adrian Klaver <[email protected]> 1 sibling, 1 reply; 5+ messages in thread From: Laurenz Albe @ 2025-11-22 00:43 UTC (permalink / raw) To: Adrian Klaver <[email protected]>; Steve Crawford <[email protected]>; pgsql-general On Fri, 2025-11-21 at 16:38 -0800, Adrian Klaver wrote: > > There was a time, like version 9-dot-something, when the above queries > > performed as expected returning midnight in the current time zone but I > > haven't been able to find a change document indicating this as an > > expected change. > > I don't remember that, but as the gray content of the hair increases the > memory is less solid:) 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). Yours, Laurenz Albe ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Unexpected date conversion results @ 2025-11-22 00:52 Adrian Klaver <[email protected]> parent: Adrian Klaver <[email protected]> 1 sibling, 0 replies; 5+ messages in thread From: Adrian Klaver @ 2025-11-22 00:52 UTC (permalink / raw) To: Steve Crawford <[email protected]>; pgsql-general On 11/21/25 16:38, Adrian Klaver wrote: > On 11/21/25 16:09, Steve Crawford wrote: >> Either there is a bug in my understanding or one in PostgreSQL. I >> expect a date value to follow the current time zone setting and be >> interpreted as midnight at the start of the given date. In many cases >> it does. Shown below are the postgresql.conf settings and the psql >> client settings showing the time zone to be America/Los_Angeles: >> >> postgresql.conf: >> log_timezone = 'America/Los_Angeles' >> timezone = 'America/Los_Angeles' >> >> Client time zone setting: >> >> steve=> show timezone; >> TimeZone >> --------------------- >> America/Los_Angeles >> >> > >> However, extracting the epoch from current_date returns 4pm the prior >> day (i.e. 2025-11-21 00:00:00-00), in other words midnight 2025-11-21 >> UTC which seems to be inconsistent behavior: > > > https://www.postgresql.org/docs/current/functions- > datetime.html#FUNCTIONS-DATETIME-EXTRACT > > "epoch > > For timestamp with time zone values, the number of seconds since > 1970-01-01 00:00:00 UTC (negative for timestamps before that); for date > and timestamp values, the nominal number of seconds since 1970-01-01 > 00:00:00, without regard to timezone or daylight-savings rules; for > interval values, the total number of seconds in the interval > " > > So epoch is in UTC which is confirmed by below. >> >> steve=> select to_timestamp(extract(epoch from current_date)); >> to_timestamp >> ------------------------ >> 2025-11-20 16:00:00-08 > > If you want it to work(I am in 'America/Los_Angeles' also): > > select to_timestamp(extract(epoch from current_date)) at time zone 'UTC'; > > timezone > --------------------- > 2025-11-21 00:00:00 Or something like: select extract(epoch from current_date); extract ------------ 1763683200 select to_timestamp(extract(epoch from current_date)); to_timestamp ------------------------ 2025-11-20 16:00:00-08 select extract(epoch from current_date::timestamptz); extract ------------------- 1763712000.000000 select to_timestamp(extract(epoch from current_date::timestamptz)); to_timestamp ------------------------ 2025-11-21 00:00:00-08 Where the latter does the rotation to the TimeZone setting via ::timestamptz and you get 28,800 second(8 hr) difference and a returned timestamptz that is correct for the TimeZone. > > >> There was a time, like version 9-dot-something, when the above queries >> performed as expected returning midnight in the current time zone but >> I haven't been able to find a change document indicating this as an >> expected change. > > I don't remember that, but as the gray content of the hair increases the > memory is less solid:) > >> >> -Steve > > -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Unexpected date conversion results @ 2025-11-22 00:55 Tom Lane <[email protected]> parent: Laurenz Albe <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Tom Lane @ 2025-11-22 00:55 UTC (permalink / raw) To: Laurenz Albe <[email protected]>; +Cc: Adrian Klaver <[email protected]>; Steve Crawford <[email protected]>; pgsql-general 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 ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Unexpected date conversion results @ 2025-11-24 19:43 Steve Crawford <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Steve Crawford @ 2025-11-24 19:43 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Laurenz Albe <[email protected]>; Adrian Klaver <[email protected]>; pgsql-general 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 ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2025-11-24 19:43 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-11-22 00:38 Re: Unexpected date conversion results Adrian Klaver <[email protected]> 2025-11-22 00:43 ` Laurenz Albe <[email protected]> 2025-11-22 00:55 ` Tom Lane <[email protected]> 2025-11-24 19:43 ` Steve Crawford <[email protected]> 2025-11-22 00:52 ` Adrian Klaver <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox