> On 24 Jan 2024, at 18:02, Aleksander Alekseev <aleksander@timescale.com> wrote:
>
> Hi,
>
>> UUIDv7 range does not correspond to timestamp range. But it’s purpose is not in storing timestamp, but in being
uniqueidentifier. So I don’t think it worth throwing an error when overflowing value is given. BTW if you will subtract
somenanoseconds - 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
withlimited precision, limited range and only if UUID was generated precisely by the specification in standard (and
standardallows 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
doinga 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).
Best regards, Andrey Borodin.