UUID → timestamp converter
Paste a UUID v7, v1 or v6 and read the creation time hidden inside, or generate min/max UUIDs from a date to run range queries on time-ordered primary keys — no library, all in your browser.
epoch timestamp shortcuts
UUID → timestamp
date / timestamp → UUID
v7 min/max are the smallest and largest valid UUIDv7 for that
instant — use them as inclusive bounds in a BETWEEN query.
v1 min/max are the equivalent timeuuid bounds for
Cassandra / ScyllaDB.
How UUIDs encode time
Only three UUID versions carry a timestamp. A UUIDv7 starts with a 48-bit big-endian count of milliseconds since the Unix epoch (00:00:00 UTC, 1 January 1970) — its first 12 hex characters are the timestamp, and the rest is random. A UUIDv1 stores a 60-bit count of 100-nanosecond intervals since 15 October 1582 (the Gregorian calendar reform), but scrambles the fields low-first, which is why v1 UUIDs don't sort by creation time. A UUIDv6 is the same 60-bit timestamp with the fields put back in big-endian order so it does sort. The common UUIDv4 is entirely random — there is no date to extract, and any decoder that claims otherwise is misreading noise. Because a v7's most significant bits are the timestamp, v7 keys are time-ordered: newer rows always compare greater, which keeps B-tree inserts append-mostly and makes date-based key ranges possible.
Querying UUIDv7 primary keys by date
If your table uses UUIDv7 keys — Postgres 18's
uuidv7(), or any of the library implementations — you can
filter rows by creation date without a created_at column.
Generate the min UUID (timestamp + version 7 + lowest valid
variant bits, all zeros after) for the start of your range and the
max UUID (timestamp + highest valid bits) for the end, then query
WHERE id BETWEEN '<min>' AND '<max>'. Both bounds
are inclusive and are themselves valid v7 UUIDs, so byte-wise comparison
does the right thing. For Cassandra's timeuuid the v1 bounds
above play the same role as minTimeuuid() /
maxTimeuuid(), computed here without a running cluster.