Message-ID: <2e2a34695d84a297e62a2996466fecf97005a2fb.camel@cybertec.at>
Subject: Re: Unexpected date conversion results
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Adrian Klaver <adrian.klaver@aklaver.com>, Steve Crawford
	 <scrawford@pinpointresearch.com>, PG-General Mailing List
	 <pgsql-general@postgresql.org>
Date: Sat, 22 Nov 2025 01:43:19 +0100
In-Reply-To: <fd3ad9cc-50da-47a4-8177-3915ad7186bf@aklaver.com>
References: 
	<CAEfWYyzvM4XcfKunhvT1_xs_9rGnbXbRvnn_znQD4-Wg-aA5Vg@mail.gmail.com>
	 <fd3ad9cc-50da-47a4-8177-3915ad7186bf@aklaver.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/2e2a34695d84a297e62a2996466fecf97005a2fb.camel%40cybertec.at>
Precedence: bulk

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=
=20
> > performed as expected returning midnight in the current time zone but I=
=20
> > haven't been able to find a change document indicating this as an=20
> > expected change.
>=20
> I don't remember that, but as the gray content of the hair increases the=
=20
> memory is less solid:)

I dug into the git history, and it has been like that since commit b3506006=
b564
in 2002 (way before version 9.x).  That commit fixed a bug that returned te=
n
time the correct reault (but still offset from the UTC epoch).

Yours,
Laurenz Albe