Note: historically, Python (and Rust) uses a local clock instead of querying exact UTC time. Now the RFC says:

For systems that do not have UTC available but do have the local time, they may use that instead of UTC as long as they do so consistently throughout the system. However, this is not recommended since generating the UTC from local time only needs a time-zone offset.

So I think it's a good idea to indicate that we're actually using time.time() and not time.gmtime() when computing the timestamps. Both implementation choices are RFC compliant, and using a local time seems to be what other languages do (if I'm wrong, please correct me as I'm no Rust expert).

Note: if A in timezone $z_A$ generates a UUIDv7 at time $t_A$, and gives it to B in timezone $z_B$, then unless B knows $z_A$, they won't be able to know about $t_A$ as u.time would give the timestamp since Unix epoch with a "hidden" offset. But I'm not comfortable with Python being the only one that is actually generating UUIDv7 objects that are UTC-based and not local-time. For UUIDv1, I prefer not to change anything and UUIDv6 is meant to be compatible with UUIDv1, so I shouldn't change one without changing the other. UUIDv7 could be using UTC-based times (namely the timestamp would be extracted using time.time_ns() - offset but I don't know if Python should be the only one doing it...)

• Issue: Customize UUIDv7 generation for database partitioning #130843

📚 Documentation preview 📚: https://cpython-previews--132154.org.readthedocs.build/