> On 24 Jan 2024, at 18:02, Aleksander Alekseev <aleksan...@timescale.com>
> wrote:
>
> Hi,
>
>> UUIDv7 range does not correspond to timestamp range. But it’s purpose is not
>> in storing timestamp, but in being unique identifier. So I don’t think it
>> worth throwing an error when overflowing value is given. BTW if you will
>> subtract some nanoseconds - you will not get back timestamp you put into
>> UUID too.
>> UUID does not store timpestamp, it only uses it to generate an identifier.
>> Some value can be extracted back, but with limited precision, limited range
>> and only if UUID was generated precisely by the specification in standard
>> (and standard allows deviation! Most of implementation try to tradeoff
>> something).
>
> I don't claim that UUIDv7 purpose is storing timestamps, but I think
> the invariant:
>
> ```
> uuid_extract_time(uidv7(X)) == X
> ```
>
> and (!) even more importantly:
>
> ```
> if X > Y then uuidv7(X) > uuidv7(Y)
> ```
>
> ... should hold.
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).
Best regards, Andrey Borodin.
