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 <[email protected]> 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.)
