The biggest fact is that there IS an official definition of what a UUID
is, and that is a 128-bit value, with a specific set of generation
methods. (and I think that is what BOOST is supporting)

Note, that the 'Type 1' official format of UUID do use 60 bits of the
UUID from a time stamp with 100ns precision, and combine that with 40
bits that uniquely identify the host (its MAC address), and additional
bits to handle identify the type of the UUID and to allow the host to
make sure that every UUID it makes are unique, even if it might make
more than 1 per 100ns. This format actually guarantees that (if the host
does its job) that there will NEVER be a duplicate, but does require the
unique MAC address.

Depending on the use, going off definition might be ok, but one key
factor is how it is going to be used.  64-bit values, IF you have a
method to make the selection of values at least fairly uniform (which
time stamps most definitely are not) then the expected number of how
many you can 'randomly' generate before getting a repeat is abut 2^32.
Depending on how bad of an effect you expect from a duplicate, that says
that 64-bit 'random' UUID shouldn't be trusted for much more than some
number of million ID in the life of the system (or at least the period
that duplicates matter).

If the 64 bits can be divided into parts, with some number of bits being
a unique identification of the system, and the rest being generated by
the system in a way that it can make sure are unique, then 64 bits could
easily be enough for many applications. This does require a central
authority to distribute system ID, the official UUID got this via the
MAC Address which most system that need UUIDs will be network connected
and thus get a MAC Address, so they could borrow that central authority.

The question comes is the 'cost' of being non-standard less than the
savings of dropping the UUID from 128-bits to 64-bits.

On 7/28/21 2:19 PM, chengm349--- via Boost-users wrote:
> how about 64-bit value if we ignore timestamps only part recommendation?
>
> Sent from my Huawei Mobile
>
>
> -------- Original Message --------
> Subject: Re: [Boost-users] UUID
> From: Richard Damon via Boost-users
> To: boost-users@lists.boost.org
> CC: Richard Damon
>
>
>     On 7/27/21 11:34 PM, Ming Cheng via Boost-users wrote:
>     >
>     > I have a UUID requirement as:
>     >
>     > * Each session will also be represented with a Universally Unique ID
>     > (UUID), which should be a current timestamp
>     > * a unique UUID value set by the customer as a 64-bit value. CME
>     > Group recommends using the system timestamp which represents the
>     > number of microseconds since epoch (Jan 1, 1970) as the timestamp.
>     > * I also need to save it in a Linux file and rebuild the UUID from
>     > the saved value.
>     >
>     > Wondering whether boost UUID code can support it?  I checked online
>     > document and seems to me quite difficulty except archiving.
>     >
>     My first thought is someone doesn't know what a UUID is. 'The Current
>     Timestamp' is NOT a UUID, and the chance of duplicates is going to be
>     reasonable high if sessions might be started on multiple machines at
>     about the same time.
>
>     --
>     Richard Damon
>
>     _______________________________________________
>     Boost-users mailing list
>     Boost-users@lists.boost.org
>     https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users@lists.boost.org
> https://lists.boost.org/mailman/listinfo.cgi/boost-users


--
Richard Damon

_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users