Non-compliance?

[BEllis]

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?

[k-bx]

+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

[stevesimmons]

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!

[nickhobbs94]

@stevesimmons just bumping thread this in case you've missed my PR (see above)

[RzNmKX]

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!

[dpldgr]

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.

[sparkcodeuk]

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..."

[dpldgr]

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.

[dpldgr]

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.

[VaZark]

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)

[RzNmKX]

From the link:

Status:Proposed Standard

[VaZark]

ah. my bad

[dpldgr]

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.

[daniel347x]

Thanks for the effort on this project. However, I just got burned adding a bunch of UUID7s and then running into glitches when testing our system, finally tracking it back down to this library - pip install uuid7 followed by from uuid_extensions import uuid7str; uuid7str() generating values that I assumed were correct but actually pointed to year 2194.

Please, please, I request that you add a MAJOR WARNING to the README that this library is broken and does not work to generate UUID7. Ideally this would be removed from pip.

So again, thanks for the effort, but whoever is managing this repository - please just take that extra moment to add one sentence of warning at the top of the README so others don't get burned.

Thanks!

[daniel347x]

...For others in the future who are burned with this issue, here is a working library for UUID7:

https://github.com/oittaa/uuid6-python

Yes, that's right - the name of the library is uuid6 and you install/import it via pip install uuid6 and import uuid6, but unlike the current library, it generates correct UUID7s via uuid6.uuid7().

[dpldgr]

Thanks for the effort on this project. However, I just got burned adding a bunch of UUID7s and then running into glitches when testing our system, finally tracking it back down to this library - pip install uuid7 followed by from uuid_extensions import uuid7str; uuid7str() generating values that I assumed were correct but actually pointed to year 2194.

Please, please, I request that you add a MAJOR WARNING to the README that this library is broken and does not work to generate UUID7. Ideally this would be removed from pip.

So again, thanks for the effort, but whoever is managing this repository - please just take that extra moment to add one sentence of warning at the top of the README so others don't get burned.

Thanks!

There is a process to take over abandoned projects on PyPI. I'll have a look into that in the coming days to see what's required. It's not hard to see that end users will expect a project named 'uuid7' to implement the latest version of the RFC rather than a very out of date draft.

@stevesimmons can you please either update this code so that it correctly implements the RFC, or remove the 'uuid7' package from PyPI so that end users don't continue to run into issues.

[nickhobbs94]

@stevesimmons
I've opened up a PyPi request to take over the package maintenance: pypi/support#4761

Happy to withdraw this if we can resolve this issue.

[dpldgr]

@stevesimmons I've opened up a PyPi request to take over the package maintenance: pypi/support#4761

Happy to withdraw this if we can resolve this issue.

Cheers Nick. Just make sure you've tried to contact him at the places they specify in their process.

[rowanseymour]

Not great that the PyPI package called uuid7 doesn't generate valid v7 UUIDs according to latest standard. If the author can't fix this can they at least archive this repo?

[mullenkamp]

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)

The newest standard does seem to have optional sub-millisecond bits:
https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7

How does this compare to the current implementation?

[nickhobbs94]

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)

The newest standard does seem to have optional sub-millisecond bits: https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7

How does this compare to the current implementation?

Unfortunately this package is still not compliant with the optional sub-milliseconds because the first 48 bits are meant to be the number of milliseconds since epoch and this library counts in nanoseconds. So here we generate a bigger number and thus uuids from this package get sorted differently to UUIDs matching the spec. The sub-millisecond fields of the spec append more bits after the millisecond count (they work like adding numbers after a decimal place), so still get sorted correctly.

[lovetox]

@nickhobbs94 should/can we do something in preparation of the maintainer change? Are you requesting the maintainer of the package just to take it down? Or are you open to maintaining a fork?

Because if we want to fork this, then we could start to do this right now, and not wait for pypi to change the maintainer.

[nickhobbs94]

@lovetox I've got a fork up (from this PR #2) but it's not published to pypi. We could publish it under a different name but I'm not sure I see much point. It was a bit of a hack together so some extra eyes/testing on it might be good.