UUIDv7 timestamp is not consistent with other implementations

[jaymecd]

What happens?

New release 1.3.0 has support for uuidv7 and that's awesome, however it's timestamp implementation is not consistent with other implementations.

• function uuidv7() generates value as 8196f946-5678-7ac0-a594-fe51da68ec69
• others implementations (uuid.lol, gofrs/uuid & etc...) generate as 0196f946-552a-76e1-9255-9c9579756e65

Both of these UUIDs are v7, both have been generated at 2025-05-22 20:34:18+02 exactly (microseconds omitted on purpose).

Using uuid_extract_timestamp() func to extract timestamp gives completely different results.

uuid_extract_timestamp('8196f946-5678-7ac0-a594-fe51da68ec69')	uuid_extract_timestamp('0196f946-552a-76e1-9255-9c9579756e65')
2025-05-22 18:22:07.96+00	2436-08-06 (BC) 15:34:49.268+00

Meanwhile, parsing UUID generated by duckdb using other implementation gives timestamp of 6485-03-07T21:20:13.944Z.

That behaviour is unexpected and makes result of uuidv7() function not portable comparing to other implementations when extracting timestamp is required.

To Reproduce

Generate UUIDv7:

duckdb:

$ duckdb -csv -noheader -c 'SELECT uuidv7()'

8196f946-5678-7ac0-a594-fe51da68ec69

golang:

uuidv7.go

package main

import (
	"fmt"
	"log"

	"github.com/gofrs/uuid/v5"
)

func main() {
	u7, err := uuid.NewV7()
	if err != nil {
		log.Fatalf("failed to generate UUID: %v", err)
	}
	fmt.Printf("%v\n", u7)
}

$ go run uuidv7.go

0196f946-552a-76e1-9255-9c9579756e65

---

Extract timestampt from UUIDv7

$ duckdb -line -c "SELECT
    uuid_extract_timestamp('8196f946-5678-7ac0-a594-fe51da68ec69') as ts_duckdb,
    uuid_extract_timestamp('0196f946-552a-76e1-9255-9c9579756e65') as ts_golang;"

ts_duckdb = 2025-05-22 20:34:18.616+02
ts_golang = 2436-08-06 (BC) 16:41:50.954+00:53

OS:

macOS 15.5 / aarch64, Ubuntu 24.04 / x86_64

DuckDB Version:

1.3.0

DuckDB Client:

cli, python (3.13)

Hardware:

arm64, amd64

Full Name:

Nikolai Zujev

Affiliation:

Deloitte

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a stable release

Did you include all relevant data sets for reproducing the issue?

Not applicable - the reproduction does not require a data set

Did you include all code required to reproduce the issue?

• Yes, I have

Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?

• Yes, I have

[Mytherin]

Thanks for the report! You are absolutely correct - I've pushed a fix in #17612 that should make us consistent with the standard.