017f22e2-79b0-7cc3-98c4-dc0c0c07398f is a version 7 (Unix Epoch time-based) UUID with the RFC 9562 variant; it was stamped at 2022-02-22 19:22:22.000 UTC.
Field layout
unix_ts_ms (48)
0
0
0
0
0
0
0
1
0
1
1
1
1
1
1
1
0
0
1
0
0
0
1
0
1
1
1
0
0
0
1
0
0
1
1
1
1
0
0
1
1
0
1
1
0
0
0
0
ver (4)
0
1
1
1
rand_a (12)
1
1
0
0
1
1
0
0
0
0
1
1
var (2)
1
0
rand_b (62)
0
1
1
0
0
0
1
1
0
0
0
1
0
0
1
1
0
1
1
1
0
0
0
0
0
0
1
1
0
0
0
0
0
0
1
1
0
0
0
0
0
0
0
1
1
1
0
0
1
1
1
0
0
1
1
0
0
0
1
1
1
1
How it's calculated S
Normalise
Lower-case hex in 8-4-4-4-12 groups: 017f22e2-79b0-7cc3-98c4-dc0c0c07398f.
Variant
octet 8=98=100110002⇒RFC 9562
Leading bits 10 mean the RFC 9562 layout; 0, 110 and 111 are reserved for older or future schemes.
Version
high nibble of octet 6=7c⇒7(Unix Epoch time-based)
Unix timestamp
bits 0–47=017f22e279b016=1645557742000ms⇒2022-02-22 19:22:22.000 UTC
Randomness
This layout leaves 74 bits for random data.
About the UUID generator and decoder
A UUID is a 128-bit identifier written as 32 hex digits in 8-4-4-4-12 groups. RFC 9562 fixes two fields in every standard UUID: the variant bits 10 at the start of the 17th hex digit, and a 4-bit version number in the 13th. The decoder reads both, then unpacks what that version carries: a 48-bit Unix millisecond timestamp for version 7, a 60-bit count of 100-nanosecond intervals since 15 October 1582 for versions 1 and 6, or 122 random bits for version 4.
The default is the RFC 9562 version 7 example, 017f22e2-79b0-7cc3-98c4-dc0c0c07398f, whose first 48 bits count 1,645,557,742,000 ms, which is 22 February 2022 at 19:22:22 UTC. Developers pick v7 for database keys because the values sort by creation time.
Generated UUIDs come from a seeded xoshiro256** generator, so the same seed always gives the same list. For identifiers that must be unguessable, use a cryptographic source such as crypto.randomUUID().
How to read a UUID's version and timestamp
A UUID is 128 bits written as 32 hex digits in 8-4-4-4-12 groups. The 13th digit is the version and the 17th carries the variant. In 017f22e2-79b0-7cc3-98c4-dc0c0c07398f the 7 marks version 7, the 9 the standard variant, and the first 12 digits count Unix milliseconds: 2022-02-22 19:22:22 UTC.
Decoding a version 7 timestamp by hand
Take the first 12 hex digits, dropping the hyphen: 017f22e279b0.
Convert to decimal: 1,645,557,742,000 milliseconds since 1970-01-01 00:00 UTC.
Divide by 1,000 for Unix seconds, 1,645,557,742, which is 2022-02-22 19:22:22.000 UTC.
RFC 9562 defines the current layouts and replaced RFC 4122 in 2024.
Version 1: a 60-bit count of 100-nanosecond intervals since 1582-10-15, a clock sequence and a 48-bit node, traditionally the machine's MAC address.
Versions 3 and 5: an MD5 or SHA-1 hash of a namespace and a name, so the same name always gives the same UUID.
Version 4: 122 random bits. Nothing else is encoded.
Version 6: version 1's timestamp reordered, high bits first, so values sort by time.
Version 7: a 48-bit Unix millisecond timestamp, then 74 random bits. New IDs sort in creation order.
Version 8: an experimental or vendor-specific layout. Only its version and variant bits are standard.
Nil and Max: all 128 bits set to 0, or all set to 1.
Check the variant before trusting the version digit. Standard UUIDs have 8, 9, a or b as the 17th digit. A c or d there marks Microsoft's reserved variant, where the 13th digit is not an RFC version.
Version 1 and version 6 side by side
The RFC's version 1 example, c232ab00-9414-11ec-b3c8-9f6bdeced846, and its version 6 twin, 1ec9414c-232a-6b00-b3c8-9f6bdeced846, hold the same instant. Both decode to 2022-02-22 19:22:22.0000000 UTC, with clock sequence 13256 and node 9f:6b:de:ce:d8:46.
Version 1 stores the low 32 time bits first, so its text sorts by the fastest-changing part of the clock. Version 6 stores the same 60 bits in order, 1ec9414c232ab00, which is why it sorts. Seven fractional digits keep the 100-nanosecond resolution.
Embedded times in the examples
Scenario
Version
Embedded UTC time
Default
7
2022-02-22 19:22:22.000 UTC
RFC v1
1
2022-02-22 19:22:22.0000000 UTC
RFC v4
4
—
RFC v6
6
2022-02-22 19:22:22.0000000 UTC
Seeded v7
7
2026-01-15 12:00:00.000 UTC
Default is the RFC's version 7 example from the first section. The RFC v4 example, 919108f7-52d1-4320-9bac-f847db4148a8, carries no time at all.
Seeded v7 is the first UUID generated from seed 42 at 2026-01-15 12:00 UTC: 019bc186-de00-7716-a104-d9866d113a7e.
Version 4 or version 7?
Use version 4 when an ID must reveal nothing. Use version 7 for database primary keys: new values land at the end of a B-tree index instead of at random positions, at the cost of exposing each record's creation time to anyone who sees the ID.
Reproducible UUIDs for tests
Generated UUIDs here come from xoshiro256**, seeded through SplitMix64 (reference code), so the same seed always gives the same list. That suits fixtures and documentation.
They are predictable by design, so never use them as session IDs, tokens or production keys. For those, use a cryptographic source such as crypto.randomUUID().
All version 7 UUIDs in one list share the millisecond you choose. Their order inside that millisecond is random; RFC 9562 section 6.2 describes counters for strictly increasing IDs.
UUID mistakes to avoid
Treating the timestamp as proof. Anyone can build a UUID with any embedded time. Use your records for when something actually happened.
Reading the version without the variant. A GUID with a c or d variant digit follows a different layout.
Comparing raw GUID bytes. Windows stores the first three groups little-endian in binary form, so a byte dump reads differently from the text.
Expecting version 4 to sort. Random UUIDs scatter across an index; switch to version 7 if insert order matters.
Accepted UUID and seed formats
Upper or lower case, with or without hyphens, braces or a urn:uuid: prefix.
Seeds from 0 to 18,446,744,073,709,551,615 (2^64 − 1), and 1 to 50 UUIDs per list.
Version 7 dates from 1970-01-01 00:00 UTC up to the year 10889.
Checked against: RFC 9562 Appendix A.5 (same instant as the v1 example)
Questions
What is the difference between UUID v4 and v7?
Version 4 fills 122 of the 128 bits with random data, so values are spread evenly and reveal nothing. Version 7, defined in RFC 9562 (May 2024), puts a 48-bit Unix millisecond timestamp first and 74 random bits after it, so new IDs sort in creation order. RFC 9562 notes that v4 has poor database-index locality, which is why v7 suits primary keys, at the cost of revealing when each ID was made.
Can two random UUIDs collide?
In practice, no. A v4 UUID has 122 random bits, so by the birthday bound you would need about 2.7 × 10^18 of them for a 50% chance of a single duplicate, or about 103 trillion for a one-in-a-billion chance. Real collisions come from faulty random number generators or reused seeds, which is why the seeded UUIDs here shouldn't be used where uniqueness across systems matters.
What is the difference between a UUID and a GUID?
They are the same 128-bit format; GUID is Microsoft's name for it. Microsoft tools often print GUIDs in upper case inside braces, such as {017F22E2-79B0-7CC3-98C4-DC0C0C07398F}, and RFC 9562 allows upper, lower or mixed case, so parsers should accept both. The one real difference is binary byte order: Windows stores the first three groups little-endian, which matters only when reading raw bytes.
How do I get the timestamp from a UUID v7?
Take the first 12 hex digits, which hold a 48-bit count of milliseconds since 1970-01-01 00:00 UTC, and convert them to decimal. For 017f22e2-79b0-7cc3-98c4-dc0c0c07398f, 017f22e279b0 is 1,645,557,742,000 ms, which is 2022-02-22 19:22:22.000 UTC. The 48-bit field runs out in the year 10889, so it will not wrap in practice.
Is a version 1 UUID a privacy risk?
It can be. Version 1 stores a 60-bit timestamp and a 48-bit node field that is traditionally the machine's MAC address, so the ID reveals when and on which network card it was made; the RFC 9562 v1 example decodes to 2022-02-22 19:22:22 UTC with node 9f:6b:de:ce:d8:46. RFC 9562 allows a random node value instead, and says to use version 7 instead of 1 or 6 where possible.
This calculator includes 8 worked examples with independently sourced answers. They run in the test suite, and you can run them here too.
Put this calculator on your site
Paste this where you want the calculator to appear. It is free to use, it stays in step with corrections made here, and the credit line below it links back so your readers can find the full version.