actually, I am doing that, I generate a random number from 0-16383 and after 
that I add 32768 onto it. 32768 is 0x8000, 32768+16383=49151 is 0xBFFF. I 
cannot really come up with a reason why this is too, but the specification is 

And yeah, we could definitely generate any other format to, but UUIDs are a 
standardized format, so I cannot imagine why it is that hard using it, because 
there are probably many people that want to use it.

Best regards

On 05.09.19, 17:38, "Geoff Simmons" <ge...@uplex.de> wrote:

    On 9/5/19 16:58, Schimweg, Luca wrote:
    > unique-id-format 
    This is going to be very nit-picky (I apologize): that comes close but
    isn't actually guaranteed to produce an RFC 4122 version 4 UUID (the
    "random" UUID).
    You're right about the 4 at the beginning of the third group of hex
    digits. But the first digit of the fourth group is required to be one of
    8, 9, a or b. I've never understood why, but there it is.
    Whether or not that matters, it seems to me, depends on requirements. If
    you just need 16 bytes of randomness for a request ID, why not just
    generate that? base64 encoding would be shorter, by the way -- 25 chars
    for base64 with padding, 36 for the UUID format.
    But if someone has an interoperability requirement dictating a UUID that
    has to meet the standard format, then I agree that a fetch that gets it
    just right would be warranted.
    ** * * UPLEX - Nils Goroll Systemoptimierung
    Scheffelstraße 32
    22301 Hamburg
    Tel +49 40 2880 5731
    Mob +49 176 636 90917
    Fax +49 40 42949753

Reply via email to