> On 24 Jan 2024, at 18:29, Aleksander Alekseev <aleksander@timescale.com> wrote:
>
> Hi,
>
>> Function to extract timestamp does not provide any guarantees at all. Standard states this, see Kyzer answers
upthread.
>> Moreover, standard urges against relying on that if uuidX was generated before uuidY, then uuidX<uuid. The standard
isdoing a lot to make this happen, but does not guaranty that.
>> All what is guaranteed is the uniqueness at certain conditions.
>>
>>> Otherwise you can calculate crc64(X) or sha256(X)
>>> internally in order to generate an unique ID and claim that it's fine.
>>>
>>> Values that violate named invariants should be rejected with an error.
>>
>> Think about the value that you pass to uuid generation function as an entropy. It’s there to ensure uniqueness and
promoteordering (but not guarantee).
>
> If the standard doesn't guarantee something it doesn't mean it forbids
> us to give stronger guarantees.
No, the standard makes these guarantees impossible.
If we insist that uuid_extract_time(uuidv7(time))==time, we won't be able to generate uuidv7 most of the time.
uuidv7(now())will always ERROR-out.
Standard implies more coarse-grained timestamp that we have.
Also, please not that uuidv7(time+1us) and uuidv7(time) will have the same internal timestamp, so despite time+1us >
time,still second uuid will be greater.
Both invariants you proposed cannot be reasonably guaranteed. Upholding any of them greatly reduces usability of UUID
v7.
Best regards, Andrey Borodin.
