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.

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

Closed
nerg4l opened this issue Jun 17, 2021 · 3 comments
Closed

Is timestamp reusable from stable storage between versions? #5

nerg4l opened this issue Jun 17, 2021 · 3 comments

Comments

@nerg4l
Copy link

nerg4l commented Jun 17, 2021

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)

  • precision: 100-nanosecond
  • epoch: 15 October 1582
timestamp = (time.time_ns() // 100) + 0x01b21dd213814000

For v7 and v8 (unix)

  • precision: variable - best case nanoseconds
  • epoch: 1 Jan 1970
timestamp = time.time_ns()
@kyzer-davis
Copy link
Collaborator

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 testing_v8.py and changing the first input from a string to a sequence of bits and then use the length to determine clockSequence and Node bits required.
def uuid8(timestampBits, timestampLength=64, customNode=None, devDebugs=False, returnType="hex"):

@nerg4l
Copy link
Author

nerg4l commented Jun 17, 2021

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?

@kyzer-davis
Copy link
Collaborator

You are right. It makes sense to have one for v6, v7, v8 at the very least.
Just another fun holdover of my fork of Python's UUIDv1 while converting to v6.

I will make the update in my latest branch to have these global vars:
_last_v6timestamp, _last_v7timestamp, _last_v8timestamp

kyzer-davis added a commit that referenced this issue Jul 12, 2021
Draft 01 Update (#2 #4 #5 and update Readme with new prototype links)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants