If we want a v7, shouldn't we use a ULID instead?

When we didn't have UUIDv7, ULID was great. But now that we have v7 it's the more widely supported alternative. And apart from v7 setting the UUID version bits and having a different default representation they are not that different.

ULID's presentation format is probably better for humans, though. You can double-click-to-highlight a ULID; the standard UUID representation doesn't like this.

(You can use ULID's presentational tools with UUIDv7, though.)

It doesn't help in other tools, but there is a css rule to help with this.

https://developer.mozilla.org/en-US/docs/Web/CSS/user-select

> You can use ULID's presentational tools with UUIDv7, though.

I did that, works pretty good: https://codeberg.org/prettyid/python

Some more context in a sibling thread: https://news.ycombinator.com/item?id=41355218

> You can double-click-to-highlight a ULID; the standard UUID representation doesn't like this.

You can control this behavior in CSS with `user-select`. Peep my fiddle: https://jsfiddle.net/gLyph5km/

Yup, in a browser you can. In my terminal or my text editor or Slack, I can't.

You're right that there isn't a good standard way to configure this, but a lot of terminals should be able to do it. The magic phrase is “word characters”. I know Konsole, gnome-terminal, iTerm2, Terminal-dot-app at least have this setting.

Yep, I know about that (and WORDCHARS in zsh, for keyboard navigation). The thing is, though, UUIDs overload the dash character. I don't want dashes to be word characters except for a UUID.

(ULID representations also are shorter because they use a wider character set, which is nice though not critical.)

> the standard UUID representation doesn't like this.

Yeah, I've gotten in the habit of stripping hyphens from the string representation of UUIDs in a lot of the code I write for that reason.

Yeah I’m sticking with ULID and Sqids for my ID/slug purposes.

Oh, I didn't realize v7 was newer than ULID, thanks.

Be careful if you're using python.

The python uuid standard library doesn't have V7 yet, and there is a package called uuid7 which is unmaintained, and not in compliance with the latest standard. That's using nanosecond time precision rather than millisecond, which means the leading bits are larger than they are meant to be.

If you use that unmaintained uuid7 package and later change to the correct implementation your uuid7 will go backwards, which is a breaking change considering that monotonicity is a key property of uuidv7.

I believe your concern, while valid, only affects systems which are currently adding records faster than 1 per nano-second on occasion.

Also while technically true - it could technically break monotonicity (records added in the same nanosecond could be out of order) they'll still be all "near the end of the file, likely in the same page" such that performance implications are negligible.

As a general rule I would avoid any program making any assumptions about a uuid. Programs should treat it as an opaque binary random value. Doing so avoids any future incompatibilities.