[go: nahoru, domu]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RFC: Consider asking the IETF to make a smarter move on UUID V7 before adopting #15

Closed
IDisposable opened this issue Jun 30, 2023 · 3 comments
Closed

RFC: Consider asking the IETF to make a smarter move on UUID V7 before adopting #15

IDisposable opened this issue Jun 30, 2023 · 3 comments

Comments

@IDisposable
Copy link

We should push for a better option (or revision to) UUID V7

From an email I sent the authors of that draft:

Given that the "Unix Epoch" value is going to Y2K us in 2038, thus meaning all the sortability of V7 UUIDs would be broken, any chance you would consider revising that format slightly?

I would propose a Epoch-Period of one or two bits at the front of the UUID field. Then right-shift the actual Unix timestamp one or two bits before injecting those values in the rest of the timestamp field in V7 format. That would only lose us one or two bits of timestamp precision while buying us either 68 or 204 more YEARS before we get Y2Ked

If we actually are building this to have some useful K-sortability, seems crazy to be asking for trouble and adopting a representation that will roll-over in 2038... that's not far away.
@IDisposable IDisposable changed the title Consider asking the IETF to make a smarter move on UUID V7 before adopting RFC: Consider asking the IETF to make a smarter move on UUID V7 before adopting Jun 30, 2023
@loreto
Copy link
Contributor
loreto commented Jun 30, 2023

The latest draft says that 36 bits are being reserved for the unix timestamp in order to extend the max timestamp until year 4147: https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-02.html#name-uuidv7-timestamp-usage

Does that address the concerns?

@IDisposable
Copy link
Author
IDisposable commented Jun 30, 2023 •
edited
Loading

That spec changed since the last time I read it, sorry. I'll make the same suggestions to the spec author via the email on the spec. Thanks for pointing that out.

It at least mitigates the problem given that you're at the mercy of the timestamp size now, I think they need to change the V7 spec a bit to include the explicit ability/requirement to set the "leading 4 zeros" to actually be the number of epoch rollovers for the spec (and thus your inherited dependency) to be resilient.

@IDisposable
Copy link
Author

My ultimate point being... when the rollover occurs ON a system where the timestamp is 32 bits, the v7 spec, and thus you by implementation will, if left unchanged, lead to a rolled-over value so after 2038-01-19 00:14:08. Those new rows will sort up to the top. :(

@loreto loreto closed this as completed Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@loreto @IDisposable