Skip to content

convert_time_to_uuid doesn't always set the uuid variant correctly #180

pcmanus opened this Issue Nov 28, 2012 · 1 comment

2 participants

pcmanus commented Nov 28, 2012

The UUID spec ( 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 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.

@thobbs thobbs added a commit that referenced this issue Jan 19, 2013
@thobbs thobbs Specify correct uuid variant in convert_time_to_uuid
Related to #180
@thobbs thobbs closed this in 7d6a6ee Jan 19, 2013
pycassa member
thobbs commented Jan 19, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.