public inbox for [email protected]  
help / color / mirror / Atom feed
From: Christophe Pettus <[email protected]>
To: Andrey Borodin <[email protected]>
Cc: [email protected]
Subject: Re: uuidv7 improperly accepts dates before 1970-01-01
Date: Mon, 27 Apr 2026 15:51:12 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>

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





reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: uuidv7 improperly accepts dates before 1970-01-01
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox