Hi, Andrey,
Thanks for the response! I'm moving it to -hackers since it's not really a bug related conversation at this point.
(resendingwith 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
canconstruct 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
surprisingexception when the time overflows that, the right answer is to caution them not to do that rather than permit
thewraparound.
And is anyone actually doing this? Using a very large interval with a large enough number of shards that wraparound is
areal possibility? (In that case, I'd argue they should construct the 48 bit field directly rather than kind of
dancingaround it by using a time shift.)
