On Fri, 2026-10-02 at 22:36 +0000, PG Bug reporting form wrote:
> PostgreSQL version: 18.6
>
> UUIDv7 stores a 48-bit Unix-millisecond timestamp, and PostgreSQL's
> documentation says its timestamp also includes sub-millisecond precision. A
> shifted timestamp 250 microseconds into the final representable millisecond
> is
> rejected as out of range, although its millisecond field is still the
> maximum
> valid value.
>
> **Reproduction:**
>
> ```sql
> SELECT uuidv7(
> (timestamptz '1970-01-01 UTC'
> + interval '281474976710655 milliseconds'
> + interval '250 microseconds')
> - clock_timestamp()
> );
> ```
>
> **Actual result:** SQLSTATE `22008`, `timestamp out of range for UUID
> version 7`.
>
> **Expected result:** Generate a UUIDv7 whose 48-bit millisecond timestamp is
> `2^48 - 1`, preserving the permitted sub-millisecond component.
I think that is a non-bug.
uuidv7(interval) gets the actual current timestamp (just like clock_timestamp
does) and adds that to the interval argument. That call is a bit later than
the clock_timestamp in your statement, so the result is maybe bigger than the
timestamp you specified, so it might exceed the maximum possible timestamp.
And anyway, discussing the oddities of uuidv7() for a timestamp in the year
10889 is somewhat irrelevant...
Yours,
Laurenz Albe
