I’m not sure of the state of that particular library, but yes, the RFC has changed significantly. For instance, the UUIDv7 format changed from the earlier draft RFC resulting in incompatibilities.

This is an example of an unmaintained UUID library in a similar situation that is currently causing incompatibilities because they implemented the draft spec. and didn’t update when the RFC changed:

https://github.com/stevesimmons/uuid7/issues/1

Any Python developer using the uuid7 library is getting something that is incompatible with the UUIDv7 specification and other UUIDv7 implementations as a result. Developers who use the stdlib uuid package in Python 3.14+ and uuid7 as a fallback in older versions are getting different, incompatible behaviour depending upon which version of Python they are running.

This can manifest itself as a developer using UUIDv7 for its time-ordered property, deploying with Python <=3.13, upgrading to Python 3.14+ and discovering that all their data created with Python 3.13 sorts incorrectly when mixed with data created with Python 3.14+.

A UUID library that is not receiving updates is quite possibly badly broken and definitely warrants suspicion and closer inspection.

▲

0x696C6961 3 hours ago | parent [-]

Alternative take: don't put draft RFCs into prod

▲

JimDabell 3 hours ago | parent [-]

It hasn’t been a draft RFC for a couple of years:

https://datatracker.ietf.org/doc/rfc9562/

The problem is not that it is a draft RFC, the problem is that the library is unmaintained with an unresponsive developer who is squatting the uuid7 package name. It’s the top hit for Python developers who want to use UUIDv7 for Python 3.13 and below.

	▲	0x696C6961 2 hours ago \| parent [-]
		The problem here is a lack of namespaces. A problem the cargo bozos decided to duplicate