How to extract the timestamp from a UUIDv7

Step 01: Confirm it is a version 7 UUID

The version is the first character of the third group: 01a16c37-766b-72b0-b69a-ea45923ae7ca. If it is 4, there is no time in the ID at all (Postgres returns NULL, the Rust crate returns None). If it is 1 or 6, the time is counted in 100-nanosecond steps since October 1582 and these steps do not apply. Why v7 replaced v4 for database keys is in UUIDv7 vs UUIDv4.

Step 02: Read the first 12 hex digits as milliseconds

0x01a16c37766b is 1,792,816,936,555. Divide by 1,000 and it is a normal Unix timestamp: October 24, 2026, 04:42:16.555 UTC. Our Unix timestamp converter turns that number into your local time. The rest of the ID is version, variant, random bits and, in many libraries, a counter. None of it is time, so sub-millisecond order cannot be read back out.

Step 03: Decode it in Python

Python 3.14 added uuid.uuid7(), and for a v7 the .time attribute is the 48-bit millisecond value. For any Python version, slice the hex:

import uuid, datetime as dt

def uuid7_time(u):
    ms = int(str(u).replace("-", "")[:12], 16)
    return dt.datetime.fromtimestamp(ms / 1000, dt.timezone.utc)

u = uuid.UUID("01a16c37-766b-72b0-b69a-ea45923ae7ca")
print(u.version, uuid7_time(u))   # 7 2026-10-24 04:42:16.555000+00:00

We ran the same decoder over IDs from four Python libraries:

uuid-utils (a Rust core) also exposes .timestamp in milliseconds, which matched our slice exactly.

Step 04: Decode it in JavaScript or Rust

JavaScript, with the ID as a string (Node, Deno, Bun or a browser):

const ms = parseInt(id.replace(/-/g, "").slice(0, 12), 16);
new Date(ms).toISOString();   // "2026-10-24T04:39:53.111Z" for our v7() ID from npm uuid 14.0.3

48 bits fit safely in a JavaScript number (the limit is 53), so no BigInt is needed; we checked that BigInt("0x" + hex) >> 80n gives the same value.

Rust, with the uuid crate 1.29 (features v7, plus v4 for the comparison):

use uuid::Uuid;
let id = Uuid::now_v7();
let (secs, nanos) = id.get_timestamp().expect("v1, v6 or v7 only").to_unix();
// our run: 01a16c35-6ddc-71c6-88e6-199d6f6ecf34 -> unix 1792816803.292 s
// Uuid::new_v4().get_timestamp() returns None

Step 05: Decode it in PostgreSQL

Postgres 18 added uuidv7() and made uuid_extract_timestamp() understand v7 (docs). We ran these in PostgreSQL 18.6 (the PGlite build, by ElectricSQL):

-- Postgres 18+
SELECT id, uuid_extract_timestamp(id) AS created FROM orders ORDER BY id DESC LIMIT 5;

-- Older Postgres: same 48 bits, by hand
SELECT to_timestamp(('x' || substr(replace(id::text, '-', ''), 1, 12))::bit(48)::bigint / 1000.0)
FROM orders;

Two things to know. uuidv7(interval '-1 hour') deliberately shifts the time it writes, so a column of these IDs can be honest-looking and an hour off by design. And the function does not check that the time is plausible: it will happily return 2202.

Step 06: Sanity-check the result before you trust it

If you use the decoded time for anything (audit trails, partitioning, "created at" on screen), compare it with an independent timestamp for a sample of rows. What we saw across 10 libraries in our UUIDv7 library test:

LiosK's uuid7 crate and uuidv7 npm package kept a true time in every test we ran; they reset to the real clock after a step back of more than 10 seconds.