As others have said, I don’t think the time was meant to be something you relied on for the object time, but more the help with indexing and sharding.

▲ mahboi 5 hours ago | parent [-]

Yeah this was odd: "Superficially, it seems that embedding a timestamp in the ID can remove the need to track the creation time in a separate database column" Who actually tried to do this?

I didn't assume uuid7 was guaranteed monotonic either. Of course not if you have different clocks. That's not the point of it.

▲ tredre3 3 hours ago | parent [-]

I have never tried to do this myself, for the obvious reasons you've stated, but postgres has a function to do it so clearly enough people did do it:

https://www.postgresql.org/docs/current/functions-uuid.html#...

    uuid_extract_timestamp ( uuid ) → timestamp with time zone
    Extracts a timestamp with time zone from a UUID of version 1 or 7. For other versions, this function returns null. Note that the extracted timestamp is not necessarily exactly equal to the time the UUID was generated; this depends on the implementation that generated the UUID.
    uuid_extract_timestamp('019535d9-3df7-79fb-b466- fa907fa17f9e'::uuid) → 2025-02-23 21:46:24.503-05

	▲	mahboi 2 minutes ago \| parent [-]
		It makes sense, since part of the UUID is a timestamp, there should exist a way to extract it.