Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vMbBm-00EFm3-1P for pgsql-general@arkaria.postgresql.org; Sat, 22 Nov 2025 00:09:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vMbBk-00AB2g-1u for pgsql-general@arkaria.postgresql.org; Sat, 22 Nov 2025 00:09:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vMbBk-00AB2Y-0d for pgsql-general@lists.postgresql.org; Sat, 22 Nov 2025 00:09:16 +0000 Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vMbBi-000o7r-1m for pgsql-general@postgresql.org; Sat, 22 Nov 2025 00:09:16 +0000 Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-343ee44d89aso3945362a91.2 for ; Fri, 21 Nov 2025 16:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pinpointresearch.com; s=google; t=1763770152; x=1764374952; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=2kJ2vVJTlcnMLu9muublvD1OzMkH6VlQ34+meUWSzVY=; b=io7DKtN65sGv8RAb5DSN4DsnAzMjh57qeRH8h5CUTfiMCv3Y8+ULzGtBdHFXkZ5Vcw alvZ72T/ejm4DWeDCHt+BSdSe3gHjdmB2LoX2WVg5p+q3TOT83+MZ7jOKSCvWRT8Mf/y RL4Gyg6kOsUShU+wrN1yZ52ZkrEj8KhiU2haeHvTNdF+HkIBZwFd8nBTjt9/Okjmdwj/ TJpsSxcl1uEs2htyWu+scTzOhllQmJQUYHstzb2ttkEofGRWQPanK9AJ2B7SgpTTEMFt YgBJ2YMRP/2veNBfaqgm2KFimy2JLIBdGgWYMU+KcYXHzOxxm+ZOkcvawa6r1Wa7/0KU aDGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763770152; x=1764374952; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2kJ2vVJTlcnMLu9muublvD1OzMkH6VlQ34+meUWSzVY=; b=XsEJ7rGqUcaEmxF23UhgWkB6Ku0f8ZywR+gpS+UY9+R/CatgfO1XPhpay0hdt9fnSw AY736E9daxR1mNnxK+x7307sh0obgeXbdm/4gueuphVzNes1U2cH2w5oKQDFkqt9Y4nf Q9N1SyF7l+r4gmvWlWW5pEGASZ06FeWtwHPNkM1qb3wmNe4fK0ZtvosDaXfI4Ehnft2w 8WShAbfTdQWQOmopShyv344hrVRrZI8sqKnaaElvIYBiati8FKaLZh7wnptM6bMkmO/o cdLZdnv0EASR2xTckJsAv98M+h90RvDZv8R+WQv/oSx6k46RZboB9KYAzmFrvz9MfXP9 KCJw== X-Gm-Message-State: AOJu0YzJrlv14SAylgJm+ZoK1MBorGMaT0nmHOfyCB49sipYSY4UOyzo V7uzHwYYn5ccuyOgOgMFhQjoAl0zTfOc0VwoPWUdiGdOrsvaMF2FrNa40W2cvHM/Or52O14IF/4 c8QyDXxaA3cHSr8pkUsPMxXdAeSQCVlAL4NDbM50MW4ogOW3xiIcbSX8= X-Gm-Gg: ASbGncsSbMvR39QWlnmS1lIly40Ch/vzlVv2rJtgyStBcwGKyf1gQlyEgKIudV4DBei CofVG/ecSA0A2qGnsuWwzmrgDG+n28oFCUbodoII5BsAIxvRh2ti9TYZgMjE9anXm8GK1rSm0wO mezs/avQsziTkEovLVwVQqpJIxkME6JH7tiID+HuvU4QVU6SMZsArh26eRw/5tDvt01UV1N88yo di9bFFtzaWxXSl7kuvz9lqE+tjXFiZ3XntV9bS3MuENMrfQh+c0MC4vzcCTk6+rSvTe52T5 X-Google-Smtp-Source: AGHT+IFbO1xwdWIblW3nPjuopOHY5HaMBV/7QOKzTQHrw/d9OodFCWsyMLPQmdfroZjMb0zZllAPob3AJIZcJ1z1QAY= X-Received: by 2002:a17:90b:3841:b0:343:6d82:9278 with SMTP id 98e67ed59e1d1-34733f36040mr4196095a91.30.1763770152151; Fri, 21 Nov 2025 16:09:12 -0800 (PST) MIME-Version: 1.0 From: Steve Crawford Date: Fri, 21 Nov 2025 16:09:01 -0800 X-Gm-Features: AWmQ_bk8L0H4TSlJI7WE2QynvV4doPvs1IKUNnr6Fwa17qh5Wd3eL4iYDun3O6c Message-ID: Subject: Unexpected date conversion results To: PG-General Mailing List Content-Type: multipart/alternative; boundary="000000000000627a5f064423bde2" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000627a5f064423bde2 Content-Type: text/plain; charset="UTF-8" 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 Here is the value returned by current_timestamp and current_date: steve=> select current_timestamp; current_timestamp ------------------------------- 2025-11-21 14:48:06.948845-08 steve=> select current_date; current_date -------------- 2025-11-21 Casting the current_date to a timestamp with time zone returns the expected value (midnight November 21 Pacific Standard Time) steve=> select current_date::timestamptz; current_date ------------------------ 2025-11-21 00:00:00-08 The output of to_char shows the same expected value: steve=> select to_char(current_date, 'YYYY-MM-DD HH24:MI:SSTZH'); to_char ------------------------ 2025-11-21 00:00:00-08 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: steve=> select to_timestamp(extract(epoch from current_date)); to_timestamp ------------------------ 2025-11-20 16:00:00-08 steve=> select to_timestamp(extract(epoch from current_date))::date; to_timestamp -------------- 2025-11-20 steve=> select to_timestamp(extract(epoch from '2025-11-21'::date))::date; to_timestamp -------------- 2025-11-20 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. -Steve --000000000000627a5f064423bde2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Either there is a bug in my understa= nding or one in PostgreSQL. I expect a date value to follow the current tim= e zone setting and be interpreted as midnight at the start of the given dat= e. 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 =3D 'America= /Los_Angeles'
timezone =3D 'America/Los_Angeles'

Clie= nt time zone setting:

steve=3D> show timezone;
=C2=A0 = =C2=A0 =C2=A0 TimeZone =C2=A0 =C2=A0 =C2=A0
--------------------= -
=C2=A0America/Los_Angeles
Here is the value returned by current_timestamp and current_date:

=
= steve=3D> select current_timestamp;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0current_timestamp =C2=A0 =C2=A0 =C2=A0
----------------------= ---------
=C2=A02025-11-21 14:48:06.948845-08
<= div>
steve=3D> select current_date;
=C2=A0current_date
--------------
=C2=A02025-11-21
Casting the current_date to a timestamp with time zone returns the expecte= d value (midnight November 21 Pacific Standard Time)

steve=3D> se= lect current_date::timestamptz;
=C2=A0 =C2=A0 =C2=A0 current_date= =C2=A0 =C2=A0 =C2=A0
------------------------
=C2=A020= 25-11-21 00:00:00-08

The output of to_char shows= the same expected value:

steve=3D> select to_char(current_date, = 'YYYY-MM-DD HH24:MI:SSTZH');
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = to_char =C2=A0 =C2=A0 =C2=A0 =C2=A0
------------------------
=C2=A02025-11-21 00:00:00-08

However, ext= racting 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:

steve=3D> select to_timestamp(extract(epoc= h from current_date));
=C2=A0 =C2=A0 =C2=A0 to_timestamp =C2=A0 = =C2=A0 =C2=A0
------------------------
=C2=A02025-11-20= 16:00:00-08

steve=3D> select to_timestamp(ex= tract(epoch from current_date))::date;
=C2=A0to_timestamp
<= div>--------------
=C2=A02025-11-20

st= eve=3D> select to_timestamp(extract(epoch from '2025-11-21'::dat= e))::date;
=C2=A0to_timestamp
--------------
=C2=A02025-11-20

There was a time, l= ike version 9-dot-something, when the above queries performed as expected r= eturning midnight in the current time zone but I haven't been able to f= ind a change document indicating this as an expected change.

=
-Steve
--000000000000627a5f064423bde2--