The UUID spec (http://www.ietf.org/rfc/rfc4122.txt) says that for the UUID variant should be 2, i.e. the left-most bit of the UUID lsb must be 1 and the second left-most one must be 0.
Both the LOWEST_TIME_UUID and HIGHEST_TIME_UUID in util.py respects that, but convert_time_to_uuid does something of its own.
More precisely, if 'randomize' is used, it completely disregard the variant that can end up being anything. Otherwise, the variant (at least the 2 left-most bits) is always set to 0, despite a commentary pretending otherwise (and unless I'm missing something).
For the 'randomize' part it's probably not a huge as I'm not sure setting a bad variant has much consequences in practice, but still I'm not sure this was the intent.
For the other parts, this is more problematic as this means that with lowest_val=True the uuid will sort after any correctly formed type 1 uuid with the same timestamp. And with lowest_val=False, there may be uuid generated through randomize that sort after the one generated with lowest_val = False.
One last problem is that when lowest_val=False is used, since datetime has a microseconds pecision, I believe that instead of using microseconds * 10, I believe (((microseconds + 1) * 10)-1) should be use so that the generated uuid is indeed the biggest possible uuid for the datetime provided.
Specify correct uuid variant in convert_time_to_uuid
Related to #180
Add 900ns to timestamp when creating highest timeuuid
Thanks for the very detailed notes!
The clock_seq_hi_variant should now be setting the variant correctly while using the lowest or highest signed byte value possible given the variant bits.