diff options
Diffstat (limited to '_posts/2023-02-12-uuid-versions.md')
| -rw-r--r-- | _posts/2023-02-12-uuid-versions.md | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/_posts/2023-02-12-uuid-versions.md b/_posts/2023-02-12-uuid-versions.md index 94c2715..ed652a2 100644 --- a/_posts/2023-02-12-uuid-versions.md +++ b/_posts/2023-02-12-uuid-versions.md @@ -130,6 +130,8 @@ oh. that seems bad. when is UUIDv6? well. there's a [draft RFC](https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format) making updates to the UUID RFC, but it doesn't solve that problem, it solves different problems. +*edit 2025-03-04*: this draft has been adopted as [RFC 9562](https://www.rfc-editor.org/rfc/rfc9562.html), obsoleting the original RFC 4122. hell yeah. + one of the cool things about UUIDv1 is that you can decode the timestamp back out of it, and you don't need a separate field for the time when your object was created, because its ID tells you when it was created. however, the weird slicing and dicing that UUIDv1 does to the timestamp field means sorting by time is complicated, since the low 32 bits come first and the high 12 bits come last. UUIDv6 puts the whole timestamp in order, so that the most significant bit is first. @@ -150,6 +152,8 @@ well, v7 is that. 48 bits of unix timestamp in milliseconds (rolls over every 89 this is the real good one. the only reason not to use it is that the RFC isn't approved so it isn't quite official yet, but if you don't need to care, find an implementation in your language of choice and go to fuckin town. +*edit 2025-03-04*: hi it’s me from the future. i have good news: the RFC was approved. i do not have more good news than that. + but what if yolo? ## version 8 |