René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[RFE] `fields` and `time_*` properties must not be used on UUIDs that are time-agnostic.","articleBody":"Currently, the `uuid.UUID` class features a `fields` argument and property which is a six-tuple of integers:\r\n\r\n- 32-bit `time_low`,\r\n- 16-bit `time_mid`,\r\n- 16-bit `time_hi_version`,\r\n- 8-bit `clock_seq_hi_variant`,\r\n- 8-bit `clock_seq_low`, \r\n- and 48-bit `node`.\r\n\r\nCurrently, those fields are only relevant when the UUID version is 1 since UUIDv3 and UUIDv5 are based on MD5 and SHA-1 respectively instead. However, the recent RFC 9562, superseeding RFC 4122, introduces one time-based UUID, namely UUIDv6 (basde on UNIX epoch instead of Gregorian epoch, and with timestamp bits ordered differently), as well as UUIDv7 and UUIDv8 that are implementation details.\r\n\r\nHere is what we can do for now:\r\n\r\n- For version 7, we can have:\r\n  - a cryptographically secure 74-bit chunk split into a 12 and 62-bit chunks, or\r\n  - a monotonous UUID with 12-bit sub-milliseconds precision chunk.\r\n- For version 8, we can have:\r\n  - a [time-based UUID with 10-ns precision](https://www.rfc-editor.org/rfc/rfc9562#name-example-of-a-uuidv8-value-t) with a 60-bit timestamp and 62 bits of random data, or\r\n  - a [name-based UUID](https://www.rfc-editor.org/rfc/rfc9562#name-example-of-a-uuidv8-value-n) which uses secure hashing algorithms such as SHA256/SHA-3/SHAKE-256 (see [here](https://www.rfc-editor.org/rfc/rfc9562#v8sha256) for an example of SHA256-based UUIDv8), or\r\n  - a *non*-cryptographically 122-bit chunk split into chunks of 48, 12 and 62-bit independent chunks. Those chunks can also be supplied by the user if they want cryptographically secure values (although I would suggest generating a UUIDv4 and change the version and variant bits manually).\r\n\r\nWith the addition of those variants, we at least have one UUID distinct from UUIDv1 featuring time-related fields. In particular, it is important to decide whether `fields[0]` is the first RFC field in the UUID *or* if this is always the first 32-bit fields. I personally think that we should say that *fields* represents the RFC fields, namely, `fields[0]` is a 32-bit integer corresponding to the 32 **LSB** (resp. **MSB**) of the 60-bit timestamp for UUIDv1 (resp. UUIDv6).\r\n\r\nFor UUIDv7, if we choose sub-ms precision, then the fields are a bit different in the sense that we now have `unix_ts_ms (48) | ver (4) | subsec_a (12) | var (2) | counter (62)`, so we should decide how to split those fields into 6 and whether it make sense to have the corresponding properties. A similar question arises for UUIDv8.\r\n\r\nWhile we could change the semantics of the fields and `time_*` properties, this could break applications that assume that `fields` are independent of the time (my understanding of *fields* is that it is independent of the time or the RFC and is only a way to partition the UUID's integral value into *32+16+16+8+8+48* bits, but such partitioning is only relevant for UUIDv1). \r\n\r\nTherefore, I really don't know how to deal with those time-based properties. I'd like to avoid breaking longstanding applications but at the same time I don't want a property to incorrectly reflect its value. If we don't change anything, `uuidv6.time_low` would actually return the 32 highest bits...\r\n\r\nEDIT: Should this actually be a PEP? because UUIDv7 and UUIDv8 are implementation-detail so maybe a PEP might be a good idea?\r\n\r\n---\r\n\r\n* #89083 \r\n* #120650\r\n* #121119\r\n","author":{"url":"https://github.com/picnixz","@type":"Person","name":"picnixz"},"datePublished":"2024-06-22T12:10:42.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/120878/cpython/issues/120878"}