What Is UUID v1?
UUID Version 1 is a timestamp-based universally unique identifier defined in RFC 4122. It encodes the current time as a 60-bit count of 100-nanosecond intervals since October 15, 1582 (the Gregorian calendar reform date), combined with a 48-bit node identifier — traditionally the MAC address of the generating machine.
A typical UUID v1 looks like: 6ba7b810-9dad-11d1-80b4-00c04fd430c8. The 1 in the third group identifies the version. The timestamp is split across the first three groups in a scrambled order — low bits first, then mid, then high — which is why v1 is not naturally sortable by string comparison.
The Internal Structure of UUID v1
The 128 bits of a UUID v1 are organized as follows:
- →time_low (32 bits): The low 32 bits of the 60-bit timestamp. Appears first in the string representation.
- →time_mid (16 bits): The middle 16 bits of the timestamp.
- →time_hi_and_version (16 bits): The high 12 bits of the timestamp plus the 4-bit version field (set to
0001). - →clock_seq (14 bits): A counter that increments if the clock is set backward or the node ID changes, preventing collisions.
- →node (48 bits): Traditionally the MAC address. Our generator uses a cryptographically random node ID to protect your privacy.
The Gregorian Epoch and 100-Nanosecond Resolution
UUID v1 uses October 15, 1582 as its epoch — the date Pope Gregory XIII introduced the Gregorian calendar. The 60-bit timestamp counts 100-nanosecond intervals from that date, giving UUID v1 a theoretical generation capacity of 10 million unique IDs per second per node. The clock sequence bits extend this further if the rate is exceeded.
The 60-bit timestamp will not overflow until approximately the year 3400 AD, making UUID v1 a long-term viable standard for any application that needs time-embedded identifiers.
Privacy Considerations: MAC Address Exposure
The original UUID v1 specification uses the MAC address as the node ID. This creates a privacy concern: anyone who receives a UUID v1 can extract the MAC address of the machine that generated it, potentially identifying the hardware and its network location.
RFC 4122 explicitly permits using a cryptographically random 48-bit value in place of the MAC address when privacy is a concern. Our generator always uses a random node ID — you get the time-embedding benefits of v1 without exposing any hardware information.
If you need a time-ordered UUID with no privacy concerns at all, consider UUID v7, which uses a Unix millisecond timestamp and is designed for modern systems.
The Clock Sequence: Collision Prevention
The 14-bit clock sequence is UUID v1's insurance policy. If the system clock is set backward (NTP correction, manual adjustment, VM migration), the same timestamp could be reused. The clock sequence is incremented in this case, ensuring the overall UUID remains unique even with an unstable clock.
On first boot or when the clock sequence state is lost, it is initialized with a cryptographically random value. This means UUID v1 is robust even in environments with unreliable clocks — a common scenario in containerized and virtualized infrastructure.
When to Use UUID v1
UUID v1 is the right choice in these scenarios:
- →Legacy system compatibility: Many older enterprise systems (Cassandra, some Oracle configurations) were designed around UUID v1. Maintaining v1 avoids costly schema migrations.
- →Distributed logging: The embedded timestamp lets you extract creation time from the ID itself, useful for log correlation across services.
- →Audit trails: When you need to verify both the time of an action and maintain a globally unique reference, v1 encodes both in a single value.
- →Apache Cassandra: Cassandra's
timeuuidtype is UUID v1. Its internal storage and clustering keys are optimized for v1's time-based structure.
UUID v1 vs. UUID v4 vs. UUID v7
UUID v1 embeds time but is not lexicographically sortable and has privacy concerns with MAC address exposure. Best for legacy systems and Cassandra.
UUID v4 is fully random, opaque, and the most widely supported. Best for user IDs, session tokens, and any context where time-ordering is not needed.
UUID v7 combines a Unix millisecond timestamp with random bits, is lexicographically sortable, and is the modern replacement for v1 in new systems. Best for database primary keys where INSERT performance matters.
Extracting the Timestamp from a UUID v1
Because the timestamp is embedded in the UUID, you can programmatically extract the creation time. In Python:
import uuid, datetime
u = uuid.UUID('6ba7b810-9dad-11d1-80b4-00c04fd430c8')
ts = (u.time - 0x01b21dd213814000) * 100 / 1e9
dt = datetime.datetime.fromtimestamp(ts, tz=datetime.timezone.utc)
# → 1998-02-04 22:13:53.578125+00:00
This makes UUID v1 a self-describing identifier — the primary key itself carries metadata about when the record was created, without needing a separate created_at column for basic time queries.
RFC 4122 Compliance
All UUID v1 identifiers generated on this page are fully compliant with RFC 4122. They use the correct variant bits (10xx), the correct version nibble (0001), and a cryptographically random node ID. They are compatible with PostgreSQL's UUID type, MySQL's BINARY(16), Apache Cassandra's timeuuid, and all major UUID libraries across Python, Java, Go, Rust, PHP, and C#.
