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.94.2) (envelope-from ) id 1sKfaz-00BXgi-6r for pgsql-bugs@arkaria.postgresql.org; Fri, 21 Jun 2024 14:50:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sKfax-002XB3-Iw for pgsql-bugs@arkaria.postgresql.org; Fri, 21 Jun 2024 14:50:31 +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.94.2) (envelope-from ) id 1sKfax-002XAv-Ay for pgsql-bugs@lists.postgresql.org; Fri, 21 Jun 2024 14:50:31 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sKfau-002qDC-I0 for pgsql-bugs@lists.postgresql.org; Fri, 21 Jun 2024 14:50:31 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 45LEoQZR590602; Fri, 21 Jun 2024 10:50:26 -0400 From: Tom Lane To: nicola.oricchio@vertigis.com cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18518: ::timestamp add minutes and seconds to the converted values In-reply-to: <18518-e16f6cc69c9ce413@postgresql.org> References: <18518-e16f6cc69c9ce413@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Thu, 20 Jun 2024 15:33:29 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <590600.1718981426.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jun 2024 10:50:26 -0400 Message-ID: <590601.1718981426@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > select dat, (dat at time zone 'utc')::timestamp without time zone from a= aa > order by 1; This will involve a time zone conversion from UTC to your current timezone setting. Possibly that's different between your two installations? The first results you show are consistent with Europe/Berlin. > 1892-12-31 23:00:00 | 1893-12-31 23:53:28 <-- it should be 1893-01-01 0= 0:00:00 This is not a bug, nor is it a recent behavioral change. If you don't like it, you can go complain to IANA's timezone database crew [1], but your odds of getting them to change it are about zero IMO. Their practice is to use a zone offset based on the representative city's local mean solar time in years before that area adopted standardized timezones. You'll find the same behavior in any other software that depends on the IANA tz data. For instance, on my Linux workstation: $ TZ=3DAmerica/New_York date --date=3D'1892-12-31 23:00:00 UTC' Sat Dec 31 18:00:00 EST 1892 $ TZ=3DEurope/Berlin date --date=3D'1892-12-31 23:00:00 UTC' Sat Dec 31 23:53:28 LMT 1892 New York is not less wonky than Berlin; they just adopted a standard zone a few years sooner, so you have to go back a little further to see the "LMT" output: $ TZ=3DAmerica/New_York date --date=3D'1880-12-31 23:00:00 UTC' Fri Dec 31 18:03:58 LMT 1880 regards, tom lane [1] https://www.iana.org/time-zones