How is a Time-based UUID / GUID madeThe time based UUID uses, apart from the version and variant, 3 more ingredients.
The timestampThe timestap is a 60 bit value, representing the number of 100 nanosecond intervals since 15 October 1582 00:00:000000000
If no UTC time can be obtained, the local time can be used. Care has to be taken that the clock ID has to be incremented when the clock is set backwards in this case.
Generally a programmer does not get the current time in 100 nanosecond intervals since 15 October 1582, but for instance in millisecond precision since 1 January 1970. In this case, to come from milliseconds to nanoseconds precision multiply the time returned from the system by 10000 and to correct the start date add an offset of 122192928000000000. (With other resolutions another multiplier needs to be applied, with other start dates another offset needs to be used. In case multiple UUIDs need to be generated at the same time according to the millisecond precision this can be done by adding 1 to this interval for for every UUID requested inside the same millisecond period. This must not be performed more than 10000 times in a millisecond period though (when we would have a timer that would increment once a microsecond the multiplier would only be 10 and at most 10 UUIDs can be returned in the same microsecond period.
When more than 1 UUID is needed per 100 nanoseconds multiple node IDs will be needed.
The clock IDThe clock ID is a 14 bit value, the initial value should be a random one, if a new timestamp appearst to be older than the previous timestamp used (for instance after a clock skew error or after a reboot where the clock was re-synchronized) the clock ID should be incremented by one.
The node IDThe node ID should preferrably an IEEE 802 MAC address a.k.a "ethernet address". IEEE 802 addressses should be unique, though some no-name manafacturers are known to re-use these addresses. The address can be from a network card of the machine where the UUID is generated, or of another machine / network card if you have control over that network card and can be absolutely sure that no other equipment will use this address to generate UUIDs. (For instance buy a network card only for its UUID, write down the UUID, enter it in a single program and then fry the network card, or buy a range of IEEE 802 addresses from the ieee.)
The IEEE 802 address can often be retrieved using the ipconfig /all or ifconfig eth0 commands, is often called "Hardware" or "Physical" address and looks like this: 08:00:20:0c:9a:66 (sometimes also a - or space is used as delimiter).
If no IEEE 802 address is available one can also generate a random part for this address, in this case the multicast bit (least significant bit of the first byte) must be set to 1, this to avoid clashes with legitimate IEEE 802 addresses. In case a random address is used uniqueness cannot be guaranteed. (The recipy in this case crate a 6 byte random number, perform an or operation on the first byte with 0x01)
Mapping the ingredients to the UUIDThe timestamp is mapped as follows to the UUID:
When the timestamp has the (60 bit) hexadecimal value: 1d8eebc58e0a7d7
The following parts of the UUID are set:: 58e0a7d7-eebc-11d8-9669-0800200c9a66. The 1 before the most significant digits of the timestamp indicates the UUID version, for time-based UUIDs this is 1.
The remaining parts of the UUID are the clock ID and the node ID.
The clock ID was 1669 and is put in the following part of the UUID: 58e0a7d7-eebc-11d8-9669-0800200c9a66. The first digit isn't a 1 because also the most significant bit is set, as mandated by the variant.
The node ID was 08:00:20:0c:9a:66. If the node ID were an generated one the first octed would have to be 09 instead of 08.
Note: the correct way to construct these identifiers is described in RFC 4122 the contents of this document is my interpretation of that document.
If you have improvements, contact information on the homepage of this host.
An agent adding logging to your java programs at runtime
The uptime of home.famkruithof.net