It depend on the UUID version you're using. Version 4 (Random) will always have that value be 4 as per RFC 9562. So 99999999-9999-9999-9999-999999999999 is a valid UUID but not a valid UUID v4. If you wanted to be pedantic the website should have been named https://everyuuidv4.com/

https://datatracker.ietf.org/doc/html/rfc9562

The last line of https://xkcd.com/566/, except it's UUID formats.

Are you suggesting we should never have made the random one, and stuck with mac address plus timestamp forever?

I think object identifiers would be better, althoug they should add another arc that does not require registration, based on: (fixed prefix).(type of identifier).(number of days past epoch).(parts according to type of identifier).(optional extra parts). (I had partially written my proposal, and I would want ITU and/or ISO (preferably ITU) to approve it and then manage it.) For example, type 0 could mean international telephone numbers, type 1 could mean version 4 IP address, type 2 could mean domain names (encoding each part as bijective base 37, from right to left), 3 could mean a combination of geographic coordinates with radio frequencies, 4 could mean telephone numbers with auto-delegated telephone extensions, etc. (I had also considered such things as automatic delegation, clock drift, etc; it is more carefully considered than UUID and some other types of identifiers.)

Sounds like you're in the realm of URNs? I don't know about that description, I think there's a benefit to a short and fixed-size ID. Though maybe for the domain name example you could have an alternate form that hashes any domain that goes over 20-30 characters.

I actually believe we shouldn't have made any of them

Oh okay. That's a pretty different suggestion from the comic.

Would you suggest random 128 bit numbers, then? Otherwise it's hard to see what else would serve the same role without being UUID in a trenchcoat. And having identifiers is important.

Yeah I would really like if UUID was just 128 bits of randomness and nothing else. The whole version thing sucks, and my point (which you are right in that the ordering is a little off) is that UUIDv4 is the only good one and the rest basically should not exist. UUIDv4 itself is ruined by the fact that it needs to have a version embedded in it because the other ones exist.

The values are hexidecimal, so all "9s" isn't the biggest UUID, but all "f's". Specifically, I think: `ffffffff-ffff-4fff-bfff-ffffffffffff`.

The "4" in the 3rd block is the only permitted value as these UUIDs are using the GUIDv4 format. I'm not sure what's going on in the 4th block, but the references and linked RFC in the Wikipedia article might reveal more details: https://en.wikipedia.org/wiki/Universally_unique_identifier#...

If you're going by hex, the biggest UUID is entirely f's, 32 of them. It's defined specially and doesn't have version or variant.

I see what you mean, but I was going by the definition of "UUID" used on everyuuid.com. The UUID of 32 "f's" isn't in the list.

But if it’s all Fs, that means you have the sign bit set, so it’s not the largest.

It’s the smallest that’s less than zero right?

I guess it's pretty subjective, but not all numeric types are signed, so I'm happy with my answer.

Your answer is good, mine was meant as a joke.

Looks like it only generates v4 UUIDs, which is a bit of a ripoff.

Also you'll find that the first character of the 4th block is forced to be 8, 9, a, or b. That's true of standard UUIDs of any version.

The 4 indicates UUIDv4.

If you were looking for the biggest hexadecimal UUID, find one with f instead of 9.

Because the 4 is always “4”, it denotes the version (uuid v4)