Bug report
According to the RFC, a uuid1 uses a 60-bit 100ns-resolution clock. I found a PR which migrated the implementation from time.time() to time.time_ns() as well (#11189).
uuid1 adds a random sequence (by default), thus I'd expect uuid1 to vary at least as much as time_ns() // 100, but experimentally it does not:
>>> print(time_ns() // 100); print(time_ns() // 100)
16823431055655424
16823431055655889
>>> print(time_ns() // 100); print(time_ns() // 100)
16823431060917457
16823431060918497
>>> print(time_ns() // 100); print(time_ns() // 100)
16823431065962507
16823431065964212
>>> print(uuid1()); print(uuid1())
67eb839e-e2a4-11ed-90d8-5f06396b3646
67eb839f-e2a4-11ed-90d8-5f06396b3646
>>> print(uuid1()); print(uuid1())
67eb83a0-e2a4-11ed-90d8-5f06396b3646
67eb83a1-e2a4-11ed-90d8-5f06396b3646
>>> print(uuid1()); print(uuid1())
67eb83a2-e2a4-11ed-90d8-5f06396b3646
67eb83a3-e2a4-11ed-90d8-5f06396b3646
Significant variations beyond the sequence start occurring around 1s on this machine, but even at 1.5 it's far from a guarantee:
>>> print(uuid1()); sleep(1.5); print(uuid1())
e33122ca-e2a4-11ed-90d8-5f06396b3646
e33122cb-e2a4-11ed-90d8-5f06396b3646
>>> print(uuid1()); sleep(1.5); print(uuid1())
e48020ea-e2a4-11ed-90d8-5f06396b3646
e48020eb-e2a4-11ed-90d8-5f06396b3646
>>> print(uuid1()); sleep(1.5); print(uuid1())
e5ceedfa-e2a4-11ed-90d8-5f06396b3646
e6b3d906-e2a4-11ed-90d8-5f06396b3646
>>> print(uuid1()); sleep(1.5); print(uuid1())
e6b3d907-e2a4-11ed-90d8-5f06396b3646
e8153e20-e2a4-11ed-90d8-5f06396b3646
Your environment
This issue was observed on a Dell Latitude 5400 (SKU 08B8) with an i5-8365U (x86_64) running Linux Mint 21.1.
It was reproduced on:
- the system Python (Python 3.10.6 (main, Mar 10 2023, 10:55:28) [GCC 11.3.0])
- python 3.11 installed via pyenv (Python 3.10.6 (main, Mar 10 2023, 10:55:28) [GCC 11.3.0])
- python 3.7 installed via pyenv (Python 3.7.16 (default, Jan 26 2023, 08:10:59) [GCC 11.3.0])
Bug report
According to the RFC, a uuid1 uses a 60-bit 100ns-resolution clock. I found a PR which migrated the implementation from
time.time()totime.time_ns()as well (#11189).uuid1 adds a random sequence (by default), thus I'd expect uuid1 to vary at least as much as
time_ns() // 100, but experimentally it does not:Significant variations beyond the sequence start occurring around 1s on this machine, but even at 1.5 it's far from a guarantee:
Your environment
This issue was observed on a Dell Latitude 5400 (SKU 08B8) with an i5-8365U (x86_64) running Linux Mint 21.1.
It was reproduced on: