0

I am creating a custom algorithm to embed info into a timeUUID. When studying the RFC 4122. In the spec, the version 1 UUID has the following structure:

 0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          time_low                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       time_mid                |         time_hi_and_version   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |clk_seq_hi_res |  clk_seq_low  |         node (0-1)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         node (2-5)                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I've found that the lower part of timestamp (rightmost 32 bits) goes in front of the ID making it the most relevant part when sorting UUID. What I do not understand is how this specification works in a way when sorting UUIDs the sorting will follow creation order.

To illustrate the question, please find two examples here where timestamp t1 > t2 but the created UUID with that timestamp will be in the reverse order.

 t1 = 137601405637595834 // 0x1e8dbbfd79f92ba
 t2 = 3617559227 // 0xd79f92bb

are transformed to the following parts

 t1_low: Uint = 3617559226 // 0xd79f92ba
 t1_mid: Ushort = 56255 // 0xdbbf
 t1_hi: Ushort = 1e8 // 0x1e8

 t2_low: Uint = 3617559226 // 0xd79f92bb
 t2_mid: Ushort = 0 // 0x0
 t2_hi: Ushort = 0 // 0x0

Since the least significant bytes are not relevant for the order in this case, I will ignore that for the sake of simplification.

The UUIDs geenrated using these timestamps are

 UUID1 = d79f92ba-dbbf-11e8-8808-000000000002
 UUID2 = d79f92bb-0000-1000-a68b-000000000004

Clearly UUID1 < UUID2 even when its timestamps are in the reverse order.

What is wrong on my analysis?

Community
  • 1
  • 1
Vercintegorix
  • 305
  • 2
  • 6

1 Answers1

0

The UUIDv1 spec deliberately puts the most entropy in the high-order bits so that keys do not sort as you expected; instead, they will be seemingly randomly yet roughly evenly distributed across the full number range regardless of creation order--just like UUIDv3/v4/v5.

If you want a sortable timestamp, add another column; using UUID as anything but an opaque identifier will end up biting you later.

StephenS
  • 1,813
  • 13
  • 19