Force UUIDv1 to use a clock sequence storage (RFC 4122)

[2d5c8f4d-4163-4998-af6c-b4c706ec080e]

BPO	44620

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['type-bug', 'library', '3.9', '3.10', '3.11'] title = 'UUIDv1 is not RFC 4122 compliant' updated_at = user = 'https://bugs.python.org/contact2' ``` bugs.python.org fields: ```python activity = actor = 'iritkatriel' assignee = 'none' closed = False closed_date = None closer = None components = ['Library (Lib)'] creation = creator = 'contact2' dependencies = [] files = [] hgrepos = [] issue_num = 44620 keywords = [] message_count = 1.0 messages = ['397392'] nosy_count = 1.0 nosy_names = ['contact2'] pr_nums = [] priority = 'normal' resolution = None stage = None status = 'open' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue44620' versions = ['Python 3.9', 'Python 3.10', 'Python 3.11'] ```

Linked PRs

• gh-124571

[2d5c8f4d-4163-4998-af6c-b4c706ec080e]

Section 4.1.5 of RFC 4122 says the following about Clock Sequence:

If the clock is set backwards, or might have been set backwards (e.g., while the system was powered off), and the UUID generator can not be sure that no UUIDs were generated with timestamps larger than the value to which the clock was set, then the clock sequence has to be changed. If the previous value of the clock sequence is known, it can just be incremented; otherwise it should be set to a random or high-quality pseudo-random value.

However, the current implementation increments the timestamp and not the clock sequence. Ref: https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Lib/uuid.py#L689-L690

[picnixz]

As discussed on the (now) closed PR, I do not think that this is an issue for UUIDv1. While the probability for having a collision is not that low when using the same timestamp, it is not worth changing a historical version (maybe still used though) that could (probably in a near future) be replaced by UUIDv6.

As such, I'm closing this one as wont fix (it would anyway be a feature and not a bug fix by the way).