-
Notifications
You must be signed in to change notification settings - Fork 16
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.
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
Is timestamp reusable from stable storage between versions? #5
Comments
Technically you are correct however this implementation of UUIDv8 is more of an exercise in "showing how the bit layout from the RFC Draft would work with two well known timestamp formats". In a real v8 the timestamp should be something other than Gregorian or Unix Epoch. Others may implement their own v8 with whatever timestamp they choose. As such, I don't expect another v8 implementation to feature two or more timestamp types in the body of the code. The implementer would use whatever timestamp source they require for the application context and then follow guidance on the rest of the bit layout as per some best practices with sequence counter of sufficient length and pseudorandom node data. I have been mauling over moving the timestamp part of this sample code into |
What about using the same "last timestamp" between v6 and v7? Is it okay to use the same variable in a "real life implementation" or would it be better to separate them? |
You are right. It makes sense to have one for v6, v7, v8 at the very least. I will make the update in my latest branch to have these global vars: |
On uuidv7-python branch reuses the same
_last_timestamp
between all versions. Maybe it would be better to store two different "last timestamp" one for unix and one for Gregorian epoch.I would like to know what is your suggestion for this. The two timestamps are fundamentally different because their epoch and precision isn't the same.
For v1, v6 and v8 (Gregorian)
For v7 and v8 (unix)
The text was updated successfully, but these errors were encountered: