The Legacy Time-Based Standards (v1 & v2)

4.1 UUID Version 1: Gregorian Time-Based

Invention Context:Version 1 was the workhorse of the OSF DCE standard. It was designed to guarantee absolute global uniqueness in a pre-internet era where "randomness" was computationally expensive and potentially unreliable. It achieved this by anchoring every ID to a specific physical machine (MAC address) and a specific moment in time.

Mechanism

1. Timestamp (60 bits): A count of 100-nanosecond intervals since 00:00:00.00, 15 October 1582. This date marks the official transition from the Julian to the Gregorian calendar.
2. Clock Sequence (14 bits): A counter maintained by the system. If the system clock is set backward (e.g., NTP adjustment) or if the Node ID changes, this sequence is incremented (or randomized). This prevents the generation of duplicate IDs for the same timestamp.
3. Node (48 bits): The IEEE 802 MAC address of the host machine.

The Sorting Problem

Despite being "time-based," v1 UUIDs do not sort chronologically when treated as byte arrays or strings. Because the time_low (least significant) bits are placed at the beginning of the UUID, the IDs are effectively shuffled. This random distribution makes them poor candidates for database primary keys.

4.2 UUID Version 2: DCE Security

Invention Context: Version 2 is an obscure adaptation of v1 designed specifically for the DCE Security Service. Its goal was to embed the identity of the user generating the data directly into the ID.

Mechanism

v2 takes the v1 layout and truncates the timestamp and clock sequence to make room for a Local Domain ID (usually a POSIX User ID or Group ID).

1. Truncate Time: The time_low field (32 bits) is replaced by the local_id (32 bits, e.g., the UID 501).
2. Truncate Clock: The lower 8 bits of the clock sequence are replaced by the local_domain (8 bits), which specifies if the ID is a Person, Group, or Organization.

Severe Limitation: Because v2 overwrites the low 32 bits of the timestamp, the effective timestamp precision drops dramatically. A v2 UUID only updates its timestamp component once every approx. 7 minutes. This means that a single user can only generate one unique v2 UUID every 7 minutes. This prevented v2 from gaining widespread adoption, and it is unsupported in most standard libraries.