Feature #19735
closedAdd support for UUID version 7
Description
Although the specification for UUIDv7 is still in draft, the UUIDv7 algorithm has been stable as the RFC progresses to completion.
Version 7 UUIDs can be very useful, because they are lexographically sortable, which can improve e.g: database index locality. See section 6.10 of the draft specification for further explanation:
https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/
require 'random/formatter'
Random.uuid_v7 # => "0188ca50-fcc0-7881-b5c5-6d55cd8fc373"
Random.uuid_v7 # => "0188ca51-0069-7304-be2e-0c3cd908789b"
Random.uuid_v7 # => "0188ca51-04aa-7b57-a6ec-c49573412a9d"
Random.uuid_v7 # => "0188ca51-0853-7979-ae37-485460e9f4f1"
# or
prng = Random.new
prng.uuid_v7 # => "0188ca51-5e72-7950-a11d-def7ff977c98"
        
           Updated by nevans (Nicholas Evans) over 2 years ago
          Updated by nevans (Nicholas Evans) over 2 years ago
          
          
        
        
      
      - Tracker changed from Bug to Feature
- Backport deleted (3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN)
        
           Updated by nevans (Nicholas Evans) over 2 years ago
          Updated by nevans (Nicholas Evans) over 2 years ago
          
          
        
        
      
      - Description updated (diff)
I edited the description: the draft RFC URL previously pointed to the 6th revision of draft-ietf-uuidrev-rfc4122bis (https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bis-06.html). But the 7th revision has already been posted. The URL now points to the IETF Datatracker page (https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/) which references all drafts and will be updated with a link to the final RFC, once it's accepted.
        
           Updated by nevans (Nicholas Evans) over 2 years ago
          Updated by nevans (Nicholas Evans) over 2 years ago
          
          
        
        
      
      - Description updated (diff)
I hadn't realized that "random/formatter" belonged to securerandom.  I closed the ruby PR and created a new PR here: https://github.com/ruby/securerandom/pull/19.  There was also another earlier PR which looks almost identical to my original PR: https://github.com/ruby/securerandom/pull/15.  I updated my PR to provide an alternative tradeoff: allow up to 12 bits of extra timestamp precision, at the cost of code complexity and a small performance penalty.  I personally would be satisfied with either PR.
        
           Updated by usa (Usaku NAKAMURA) about 2 years ago
          Updated by usa (Usaku NAKAMURA) about 2 years ago
          
          
        
        
      
      We core committers discussed this issue on DevMeeting, and we accepted it.
Go ahead
        
           Updated by hsbt (Hiroshi SHIBATA) about 2 years ago
          Updated by hsbt (Hiroshi SHIBATA) about 2 years ago
          
          
        
        
      
      - Status changed from Open to Closed