← Back to context

Comment by 0x20cowboy

15 hours ago

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.

3 comments

0x20cowboy

Reply
mahboi  15 hours ago

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  13 hours ago

    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  10 hours ago

      It makes sense. Since part of the UUID is a timestamp, there should exist a way to extract it.