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

On Fri Jun 12, 2026 at 10:35 PM UTC, Baji Shaik wrote:
> On Thu, Jun 11, 2026 at 2:20 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
> wrote:
>
>> I think we should go ahead and add both upper and lower bound checks,
>> barring objections.
>>
>
> Thanks Masahiko. Here's a patch series that adds both boundary
> checks along with the infinity check from my earlier patch:
>
> 0001 - Reject timestamps before the Unix epoch (lower bound)
> 0002 - Reject infinite intervals
> 0003 - Reject timestamps beyond the 48-bit field limit (upper bound)
>
> Christophe's original v1 covered the pre-epoch case; 0001 is
> essentially the same fix with slightly different wording. I have
> included it here so the series is self-contained and applies
> cleanly on HEAD. Happy to drop it in favor of Christophe's
> version if you prefer that.
>
> The infinity check (0002) goes before the epoch conversion so
> that uuidv7('infinity'::interval) gets a clear "infinite timestamps"
> message rather than falling through to the pre-epoch check
> with a confusing detail.
>
> All three use ERRCODE_DATETIME_VALUE_OUT_OF_RANGE with errdetail.
>
> Thanks,
> Baji Shaik.

> +-- uuidv7(interval) rejects timestamps before the Unix epoch
> +SELECT uuidv7('-1000 years'::interval);
> +ERROR: timestamp out of range for UUID version 7
> +DETAIL: UUID version 7 does not support timestamps before the Unix epoch.

You might want to steal the test in my patch. You never know if Postgres
will be around in 3070, and then this test will start to fail. Slightly
joking... lol

> +-- uuidv7(interval) rejects timestamps that overflow the 48-bit field
> +SELECT uuidv7('8920 years'::interval);
> +ERROR: timestamp out of range for UUID version 7
> +DETAIL: UUID version 7 does not support timestamps beyond approximately year 10889.

I think it might better to derive the interval similar to what I am
suggesting in my first comment.

Neither comment should block merging, and feel free to completely ignore
them. Just personal preference on my part.

Good work. Great minds think alike!

--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)