Hacker News new | ask | show | jobs
by hn_user2 1310 days ago
My only wish is that UUIDs were sortable and still contained their timestamp. When bug hunting, sometimes things become a little more obvious when there is an exact start and end to ids with issues.
7 comments

There are KSUIDs that aim to satisfy this

A go ref impl: https://github.com/segmentio/ksuid

Depends on the version used. Some of them do encode time. But since people don’t like to leak information they use the random version (4).
They're little endian so not sortable
What does that have to do with anything?
>>>> My only wish is that UUIDs were sortable and still contained their timestamp. When bug hunting, sometimes things become a little more obvious when there is an exact start and end to ids with issues.

>>> Depends on the version used. Some of them do encode time.

Encoding time isn't enough, it has to be big endian (unless you write a special sorting function for uuids). Timestamped uuids store the timestamp as [timestamp_low, timestamp_mid, version(!), timestamp_high][1] which doesn't sort right.

[1] https://en.m.wikipedia.org/wiki/Universally_unique_identifie...

According to that Wikipedia page the binary representation of UUID 1 is big endian. It's the date-time and MAC address version.
The whole 128-bit value is encoded in big endian. But the fields decompose into something that's not. If you search the page for "UUID record layout" you'll find the timestamp as I've described it.
You can use ULID and store it as UUID since they are the same size. You can check this article for the details:

https://blog.daveallie.com/ulid-primary-keys

UUIDv7 is sortable by time but I’m not sure if it’s possible to derive the time stamp from the UUID somehow.
The first 48 bits of uuidv7 is the number of microseconds since the epoch.
I’ve always liked the pattern of putting timestamps on any objects in my DBs.
I implemented it myself. Was a little bit tricky, but not rocket science.
Mongodbs ObjectId has this property.