
Show HN: Timeflake, 128-bit roughly-ordered UUIDs - amzans
https://github.com/anthonynsimon/timeflake/blob/master/README.md
======
amzans
Hi everyone! Just wanted to mention the use case for this:

1) You want to have UUIDs in URLs that are not predictable (vs auto-increment
integers).

2) So they should be random, but roughly-ordered over time so that your
MySQL/Postgres indices stay fast and efficient as the dataset grows.

3) And simple to use across multiple machines (no coordination or centralized
system required to generate).

4) It would be nice if they were compatible with standard 128-bit UUID
representations (many libraries in Python handle uuid.UUID, but no third-party
types).

Checkout the "Why?" section in the readme for a comparison to some of the
alternatives.

Also if you don't want to have to use this library:

    
    
      import os
      import uuid
      import time
    
      timestamp = int(time.time() * 1000)
      randomness = int.from_bytes(os.urandom(10), byteorder='big', signed=False)
      value = ((timestamp << 80) | randomness).to_bytes(16, byteorder='big')
    
      uuid.UUID(bytes=value)  
      >>> UUID('016fd379-198f-3327-2bf0-d2a0f5d863d7')
    
    

Feel free to ask me anything.

~~~
kseistrup
When using the .uuid property, flakes will occasionally collide with e.g.
UUIDv1, UUIDv4, and UUIDv5 – to mention a few regularly encountered UUID
versions – but it won't make any sense to try to parse the information then
(except, perhaps for v4).

Does the UUID specs have a version number that flakes could “naturally” belong
to?

