| You say it's breaking the spec, but is it? From https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-versio...: "UUIDv7 values are created by allocating a Unix timestamp in
milliseconds in the most significant 48 bits and filling the
remaining 74 bits, excluding the required version and variant bits,
with random bits for each new UUIDv7 generated to provide uniqueness
as per Section 6.9. Alternatively, implementations MAY fill the 74
bits, jointly, with a combination of the following subfields, in this
order from the most significant bits to the least, to guarantee
additional monotonicity within a millisecond: 1. An OPTIONAL sub-millisecond timestamp fraction (12 bits at
maximum) as per Section 6.2 (Method 3).
2. An OPTIONAL carefully seeded counter as per Section 6.2 (Method 1
or 2).
3. Random data for each new UUIDv7 generated for any remaining
space."
Which the referenced "method 3" is:"Replace Leftmost Random Bits with Increased Clock Precision (Method 3): For UUIDv7, which has millisecond timestamp precision, it is possible to use additional clock precision available on the system to substitute for up to 12 random bits immediately following the timestamp. This can provide values that are time ordered with sub-millisecond precision, using however many bits are appropriate in the implementation environment. With this method, the additional time precision bits MUST follow the timestamp as the next available bit in the rand_a field for UUIDv7." |