> UUID Version 2 (v2) is reserved for security IDs with no known details. Only no known details if the only document you're reading is the notoriously poorly-s

> UUID Version 2 (v2) is reserved for security IDs with no known details. Only no known details if the only document you're reading is the notoriously poorly-specified RFC. Here you go: https://pubs.opengroup.org/onlinepubs/9696989899/chap5.htm#tagcjh_08_02_01_01 https://pubs.opengroup.org/onlinepubs/9696989899/chap5.htm#t... There are also “version 0” UUIDs that you are very unlikely to ever come across but should be noted because they are the source of the reserved bits (via wastefully setting aside an entire octet for Address Family) that later allowed the other “versions” to be specified in a compatible way. Read my research about them here in my UUID library: https://github.com/okeeblow/DistorteD/blob/NEW%E2%80%85SENSATION/Globe%20Glitter/lib/globeglitter/chrono_diver.rb#L61-L141 https://github.com/okeeblow/DistorteD/blob/NEW%E2%80%85SENSA... I decided to support them Because It's Cool™ but still need to figure out how to handle the date rollover of them and the even-older Apollo UIDs: irb> ::GlobeGlitter::from_ncs_time => "#<GlobeGlitter 40639cd25341.02.00.00.e0.4c.18.00.69>" irb> ::GlobeGlitter::from_ncs_time.to_time => 1988-12-21 14:52:02 UTC irb> ::GlobeGlitter::from_aegis_time => "#<GlobeGlitter 00000000-0000-0000-4814-17c8b0080069>" (Proper AEGIS `#to_str` not implemented yet lol)