Python uuidv7 still currently right-pads with four zeros to turn 32 bit timestamp to 36 bit timestamp

[CMCDragonkai]

According to the discussions here uuid6/uuid6-ietf-draft#21 and the current spec:

https://github.com/uuid6/uuid6-ietf-draft/blob/master/draft-peabody-dispatch-new-uuid-format-02.txt#L597-L601

It says that:

   In the event that 32 bit Unix Timestamp are in use; four zeros MUST
   be appended at the start in the most significant (left-most) bits of
   the 32 bit Unix timestamp creating the 36 bit Unix timestamp.  This
   ensures sorting compatibility with 64 bit unix timestamp which have
   been truncated to 36 bits.

However the python implementation instead has:

    ### Need subsec_a (12 bits), subsec_b (12-bits), and subsec_c (leftover bits starting subsec_seq_node)
    unixts = f'{sec:032b}'
    unixts = unixts + "0000" # Pad end with 4 zeros to get 36-bit

Which pads with 4 zeros afterwards.

Is this wrong?

Also if we're intead using a timestamp that is neither 64 bits nor 36 bits, say 42 bits, then do we still pad with 0s? In that case it should be sufficient to just use f'{sec:036b}' right? That will format it appropriately.

[kyzer-davis]

Yes, I need to merge @fabiolimace recommended changes from #2 (comment)

Let me do that an open a new PR to get the v6/v7 python implementation compliant Draft 02.