> On 24 Jan 2024, at 18:29, Aleksander Alekseev <aleksan...@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 is doing 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 promote ordering (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.
