Re: uuidv7 improperly accepts dates before 1970-01-01

On Wed, May 27, 2026 at 6:01 PM Baji Shaik <baji(dot)pgdev(at)gmail(dot)com> wrote:
>
> Hello Masahiko,
>
> On Wed, May 27, 2026 at 7:02 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>
>> I guess it would be safer to raise an error in such cases rather than
>> silently allowing wraparound. Otherwise, users might only realize that
>> their UUIDv7 values are no longer sortable years down the road, which
>> would be disastrous. Moreover, raising an error would be consistent
>> with how PostgreSQL natively handles timestamp + interval overflows.
>
>
> +1. I ran into the same issue while testing, specifically,
> uuidv7('infinity'::interval) overflows int64 during the epoch
> conversion and produces a UUID with an incorrect timestamp.
> There's no valid use case for infinity as a shift offset.

Yeah, I think we should reject such cases at least.

> I have a small patch that adds a TIMESTAMP_NOT_FINITE check after
> timestamptz_pl_interval(), which catches both infinity and
> -infinity. Happy to extend it to also cover the 48-bit upper/lower
> bound checks if we agree on the direction.

I think we should go ahead and add both upper and lower bound checks,
barring objections.

The current behavior silently produces UUIDs with nonsensical
timestamps when the interval causes the result to go before the Unix
epoch or beyond what 48 bits can represent. Regarding backward
compatibility: this change would affect applications using
uuidv7(interval) with values that cause the resulting timestamp to
fall outside the representable range. But I guess that in practice,
any such application is likely already getting incorrect results due
to wraparound, so the risk of breaking working use cases seems very
low.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com