uuid7
uuid7 copied to clipboard
stevesimmons
Non-compliance?
I appreciate v7 is still in draft, however, UUIDv7 specifies the timestamp part as,
the number of milliseconds seconds since midnight 1 Jan 1970 UTC, leap seconds excluded.
and
For other levels of precision UUIDv8 SHOULD be utilized.
Yet this library appears to use seconds and fractions (ns?) instead of epoch ms?
+1. For anyone also encountering this there's https://github.com/aminalaee/uuid-utils that's compatible, but I'm sure there are plenty people like myself that found this library and started using it, so please fix this ASAP
Hi guys. Thanks for the suggestions. I'll at those references and adjust as soon as work allows.
Feel free to nudge me if you want it to happen quicker!
@stevesimmons just bumping thread this in case you've missed my PR (see above)
Got a comment on my blog regarding my site that I put together using this Python implementation (uuid7.com). A reader entered the example UUID7 (017F21CF-D130-7CC3-98C4-DC0C0C07398F) from the draft spec (https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-03.html#name-example-of-a-uuidv7-value), and expected to see 2022-02-22 2:22:22. The result from this library is Fri, 24 Sep 1982 19:18:21 GMT. Another nudge/bump!
I personally am ok with the extra resolution/precision of the time. Would be great if it could be specified!
Got a comment on my blog regarding my site that I put together using this Python implementation (uuid7.com). A reader entered the example UUID7 (017F21CF-D130-7CC3-98C4-DC0C0C07398F) from the draft spec (https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-03.html#name-example-of-a-uuidv7-value), and expected to see 2022-02-22 2:22:22. The result from this library is Fri, 24 Sep 1982 19:18:21 GMT. Another nudge/bump!
I personally am ok with the extra resolution/precision of the time. Would be great if it could be specified!
It's best to refer to the most recent draft (currently v14) at:
https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/
As this repo clearly shows, draft standards can be moving targets and changes to the draft can cause lots of issues with early implementations. It doesn't look like the standard is too far away from being published, so the latest draft should be quite stable now compared with two years ago.
Ah ok, I assume this'd be why I'm seeing odd UUIDs coming out of it which when you extract the timestamp info resolves to dates ca. 2191. With this kind of bug this library is unusable.
I would strongly recommend the author push an obvious warning in the README to that effect as one big reason to use v7 UUIDs is their ability to be sortable (with millisecond resolution) and to be able to extract the date/time out of it (normally UTC). You wouldn't want someone to use this library in production with such an obvious bug.
E.g.,
[datetime.datetime.now().isoformat(), uuid_extensions.uuid7()] ['2024-01-31T13:23:39.126235', UUID('065ba49d-b205-71fc-8000-2cefb0466f7c')]
"065ba49d-b205-71fc-8000-2cefb0466f7c" resolves to "2191-07-11 13:46:28.741+00"
You should be seeing UUIDv7's with values more like this: "018d5fb2-6583-7059-b4b6-eb7fffcb3da1", i.e., starting ~"018..."
Ah ok, I assume this'd be why I'm seeing odd UUIDs coming out of it which when you extract the timestamp info resolves to dates ca. 2191. With this kind of bug this library is unusable.
It's not so much a bug as it is an implementation of an early version of draft standard containing UUIDv7. Even now, it's standardisation is close to being finalised but isn't quite there yet. I wouldn't expect it to change from here, but until it's standardisation has been completed there is small chance that it could.
Hi guys. Thanks for the suggestions. I'll at those references and adjust as soon as work allows.
Feel free to nudge me if you want it to happen quicker!
Hi Steve, I can appreciate you might be short on time with work commitments, but would it be possible to remove the uuid7 python package that's in distribution? It's not helpful to have such a package widely distributed unless it's implementing the most recent version of the draft standard imho.
The new UUID standard has been officially adopted: https://www.rfc-editor.org/rfc/rfc9562
Can the library be updated if necessary? (I just found out about UUID7 & the RFC)
Note that the original RFC 4122 is also a "Proposed Standard", and was for almost 20 years. The new UUID formats are now a published RFC and can be relied upon. It might never become an IETF "Internet Standard", as very few RFCs do.