How is a Time-based UUID / GUID made

The time based UUID uses, apart from the version and variant, 3 more
ingredients.

A timestamp.

A clock ID (initially based on a random number).

A node ID (preferrably from an IEEE 802 address).

The timestamp

The 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 ID

The 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 ID

The 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 UUID

The 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.