Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\))
Subject: Re: uuidv7 improperly accepts dates before 1970-01-01
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: <799A70FA-6E5C-4118-99EB-2FBBE1CBAC54@thebuild.com>
Date: Sat, 25 Apr 2026 17:26:51 +0500
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <966B5430-8ECD-48FA-B56F-22452D9CDBBF@yandex-team.ru>
References: <799A70FA-6E5C-4118-99EB-2FBBE1CBAC54@thebuild.com>
To: Christophe Pettus <xof@thebuild.com>
Archived-At: <https://www.postgresql.org/message-id/966B5430-8ECD-48FA-B56F-22452D9CDBBF%40yandex-team.ru>
Precedence: bulk


> On 25 Apr 2026, at 05:19, Christophe Pettus <xof@thebuild.com> wrote:
>=20
> "Don't do that" is one answer, but for good hygiene, here's a patch =
that adds a < 0 check and a regression test.

Hi Christophe!

We intentionally left ability to overflow unix_ts_ms bits. In some cases =
one might want to
intentionally break time locality by using construction like SELECT =
uuidv7(INTERVAL '1000 years' * shard_id);
This will give time locality for UUIDs generated on each shard. We =
consulted with RFC authors
about this feature, and they confirmed that shifting time is compliant =
with RFC wording.
We wrote the specific test that ensures vast space for shift, but not =
unlimited.

Time shifting would become a footgun if we throw an exception when =
overflown.
If you use SELECT uuidv7(INTERVAL '-1000 years'); for generating =
identifiers, they will still be unique and
time-local, and more over - they will be ascending for a single backend. =
So no documented guarantees
are broken.

Thank you!


Best regards, Andrey Borodin.=