Re: date_trunc invalid units with infinite value

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Joseph Koshakow <koshy44(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: date_trunc invalid units with infinite value
Date: 2025-08-07 02:51:37
Message-ID: aJQUuQw0mDfGRig-@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 07, 2025 at 09:06:25AM +0900, Michael Paquier wrote:
> Yes, confirmed the broken case on 32-bit builds with the incorrect
> result returned by timestamptz_trunc_internal():
> SELECT date_trunc( 'week', timestamp with time zone 'infinity' );
>
> 0001 four new tests for timestamptz:
> 1) Three tests for timestamptz_trunc():
> - TIMESTAMP_NOT_FINITE + a valid unit, new path.
> - TIMESTAMP_NOT_FINITE + "not supported" unit, new path.
> - !TIMESTAMP_NOT_FINITE +

Blurp here. I meant !TIMESTAMP_NOT_FINITE with unsupported unit, old
code path.

> 2) One test for timestamptz_trunc_zone():
> - !TIMESTAMP_NOT_FINITE + "not supported" unit

There can be an extra test here, for the case of an infinite value
with a valid unit and a time zone specified, which would also have
failed with the bug as timestamptz_trunc_internal() is also used by
timestamptz_trunc_zone(), like:
SELECT date_trunc( 'week', timestamp with time zone 'infinity', 'GMT')
AS inf_zone_trunc;

I have added one more test, reversed the order to avoid spurious
failures should one have the idea to do a bisect with a 32b build, and
applied both things.

Thanks for the report!
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2025-08-07 03:50:53 Re: Logical Replication of sequences
Previous Message Thomas Munro 2025-08-07 02:43:17 Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events