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

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                
--------------------------------------
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.)