This occurred to me after looking at the Wikipedia article [1], and seeing the different "versions" and the rationale about not leaking data in the ID.

In general, if you want to encode info in your IDs, you can do that. Just make sure you want to do that, and that you don't run out of entropy.

I view random UUIDs as a silver-bullet type solution to assigning IDs, without overlap. (8 bytes should be enough to just assign them at random)

1: https://enwp.org/UUID

8 bytes will have a non-negligible (say, 1 in 1 million) chance of generating the same identifier twice even if you only generate a few million million IDs -- see https://en.wikipedia.org/wiki/Birthday_problem#Probability_t... and look at the "16 hex digits" row. Depending on your use case, this may or may not be a problem.

Microsoft research has a great blog post on this.

https://devblogs.microsoft.com/oldnewthing/20160114-00/?p=92...

TLDR: It's far more likely for a UUIDv1 to be corrupted to a collision due to memory errors and bit-flips, than for two UUIDv4 to collide.

TLDRTLDR: All computing is approximate at scale.

I had not considered that. In my use case it's not an issue, but I can see that if the ID value is publicly viewable (ie, in a URL) and can reveal sensitive info via the timestamp... thanks.