Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.8\))
Subject: Re: uuidv7 improperly accepts dates before 1970-01-01
From: Christophe Pettus <xof@thebuild.com>
In-Reply-To: <966B5430-8ECD-48FA-B56F-22452D9CDBBF@yandex-team.ru>
Date: Mon, 27 Apr 2026 15:51:12 -0700
Cc: pgsql-hackers@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E3B0C0EF-E9F3-4DCE-9F36-0C048E1D46D6@thebuild.com>
References: <799A70FA-6E5C-4118-99EB-2FBBE1CBAC54@thebuild.com>
 <966B5430-8ECD-48FA-B56F-22452D9CDBBF@yandex-team.ru>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Archived-At: <https://www.postgresql.org/message-id/E3B0C0EF-E9F3-4DCE-9F36-0C048E1D46D6%40thebuild.com>
Precedence: bulk

Hi, Andrey,

Thanks for the response!  I'm moving it to -hackers since it's not =
really a bug related conversation at this point.  (resending with the =
right list this time!)

> On Apr 25, 2026, at 05:26, Andrey Borodin <x4mmm@yandex-team.ru> =
wrote:

> We consulted with RFC authors
> about this feature, and they confirmed that shifting time is compliant =
with RFC wording.

Time shifting doesn't automatically imply allowing a pre-epoch input =
time to construct a UUIDv7, though, just that you can construct a UUIDv7 =
with something other than wall-clock time.

> We wrote the specific test that ensures vast space for shift, but not =
unlimited.

That's another problem: the API gives the impression of a much larger =
space than actually exists.

# select uuidv7('100000 years'::interval);   # ~11.2 x total time range =
in a UUID v7.
               uuidv7               =20
--------------------------------------
37b45c74-469d-7e1b-9397-1a971a99ab2b
(1 row)

At a minimum, it should reject a shift that creates a time later than a =
UUID v7 can represent.

> Time shifting would become a footgun if we throw an exception when =
overflown.

I don't understand why.  If the concern is that someone will pick a =
value that's close to the maximum, and get a surprising exception when =
the time overflows that, the right answer is to caution them not to do =
that rather than permit the wraparound.

And is anyone actually doing this?  Using a very large interval with a =
large enough number of shards that wraparound is a real possibility?  =
(In that case, I'd argue they should construct the 48 bit field directly =
rather than kind of dancing around it by using a time shift.)=