I was a bit confused because this document is a draft and I couldn't find any mention of "approval." But here's a link to the published RFC that obsoletes the original UUID RFC 4122:

https://www.rfc-editor.org/rfc/rfc9562

In retrospect it is super obvious that you'd want a time-ordered UUID with a random offset. I wonder how they managed to screw up 5 iterations of UUID that were basically useless to most developers.

Lots of typos in this document:

> The format for the 16-octet, 128-bit UUIDv6 is shown in Figure 2

Figure 2 is a uuidv7

> UUIDv8 SHOULD only be utilized if an implementation cannot utilize UUIDv1, UUIDv6, or UUIDv8

Probably meant this say or uuidv7

Hopefully this has been fixed...

> UUIDv8 SHOULD only be utilized if an implementation cannot utilize UUIDv1, UUIDv6, or UUIDv8

Did they mean UUIDv7 for the last one?

The clocks of systems using this UUIDs may at some point use an external NTP server for synchronization, and may cause problems without something being designed to check this (e.g. older and overflow time stamps).

Take care.

I'm curious as to why they initially chose the Gregorian calendar for dates and then stuck with it for the v6 implementation.

[flagged]