3 ms·
> So it is explicitly mentioned in the RFC as optional […] The use of rand_a for extra monotonicity is optional. The monotonicity itself is not optional. §5.7
by throw0101c 2y ago
> So it is explicitly mentioned in the RFC as optional […]
The use of rand_a for extra monotonicity is optional. The monotonicity itself is not optional.
§5.7 states:
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:
Guaranteeing additional monotonicity means that there is already a 'base' level of monotonicity, and there are provisions for even more ("additional") levels of it. This 'base level' is why §6.2 states:
Monotonicity (each subsequent value being greater than the last) is
the backbone of time-based sortable UUIDs. Normally, time-based UUIDs
from this document will be monotonic due to an embedded timestamp;
however, implementations can guarantee additional monotonicity via
the concepts covered in this section.
"Backbone of time-based sortable UUIDs"; "additional monotonicity". Additional: adding to what's already there.
* https://datatracker.ietf.org/doc/html/rfc9562 https://datatracker.ietf.org/doc/html/rfc9562
- reshlo 2y ago> Normally, time-based UUIDs from this document will be monotonic due to an embedded timestamp; however, implementations can guarantee additional monotonicity via the concepts covered in this section. “Normally, I am at home because I do not have a reason to go out; however, sometimes I am at home because I am sleeping.” Notice how this statement does not actually mean that I am always at home.
- Dylan16807 2y ago"this monotonicity" that OP suggests people not use is specifically the additional monotonicity. Or to put it another way: OP is suggesting you don't depend on it being properly monotonic, because the default is that it is only partially monotonic.
- fc417fc802 2y ago[dead]