Я создаю собственный алгоритм для встраивания информации в timeUUID . При изучении RFC 4122 . В спецификации UUID версии 1 имеет следующую структуру:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Я обнаружил, что нижняя часть метки времени (крайняя справа 32 бита) идет перед идентификатором, что делает ее наиболее важной частью при сортировке UUID.
Что я не понимаю, так это , как эта спецификация работает таким образом, что при сортировке UUID сортировка будет следовать порядку создания .
Чтобы проиллюстрировать вопрос, найдите два примера здесь, где временная метка t1> t2, но созданный UUID с этой временной меткой будет в обратном порядке.
t1 = 137601405637595834 // 0x1e8dbbfd79f92ba
t2 = 3617559227 // 0xd79f92bb
преобразуются в следующие части
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
Поскольку в этом случае младшие значащие байты не относятся к порядку, я буду игнорировать это для упрощения.
UUID, сгенерированные с использованием этих временных меток, равны
UUID1 = d79f92ba-dbbf-11e8-8808-000000000002
UUID2 = d79f92bb-0000-1000-a68b-000000000004
Очевидно, что UUID1
Что не так в моем анализе?