search

stevesimmons / uuid7

UUID version 7, which are time-sortable (following the Peabody RFC4122 draft)
MIT License
91 stars 8 forks source link

Non-compliance? #1

Open BEllis opened 1 year ago

BEllis commented 1 year ago

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 commented 1 year ago

+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 commented 1 year ago

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 commented 10 months ago

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

RzNmKX commented 9 months ago

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 commented 9 months ago

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

dpldgr commented 7 months 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.

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 commented 7 months ago

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 commented 3 months ago

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 commented 3 months ago

From the link:

Status:Proposed Standard

VaZark commented 3 months ago

ah. my bad

dpldgr commented 3 months ago

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 commented 1 week ago

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 commented 1 week ago

...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 commented 6 days ago

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 commented 5 days ago

@stevesimmons I've opened up a PyPi request to take over the package maintenance: https://github.com/pypi/support/issues/4761

Happy to withdraw this if we can resolve this issue.

dpldgr commented 5 days ago

@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 commented 2 days ago

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?