Extract Timestamp from Snowflake, ObjectId and ULID
Several widely used identifier formats embed the moment they were created. If all you have is an id, you can often recover a timestamp without touching the database.
This page opens in extract mode.
What carries a timestamp
- Snowflake - 41 bits of milliseconds since a service-specific epoch, offset from 1970. Used by X and Discord, so a message or account id reveals its creation time.
- MongoDB ObjectId - the leading 4 bytes are seconds since the epoch, so every document knows when it was inserted.
- ULID - a 48-bit millisecond timestamp in Crockford Base32.
- UUID v7 - 48 bits of milliseconds in the leading field.
Why this is useful
During an incident you frequently have an id from a log line and no corresponding row, either because it was deleted or because you are looking at the wrong shard. The embedded time narrows the window immediately.
It also settles ordering questions: two Snowflakes or two ULIDs sort chronologically by their raw string, so you can tell which event came first without any lookup at all.
What it discloses
The same property is an information leak when these ids are public. Exposed sequential or time-ordered identifiers let anyone read creation times, infer signup order, and estimate volume by sampling. Where that matters, keep the time-ordered id internal and expose a random one.
Not every identifier carries a time
UUID v4 is entirely random and discloses nothing. A hash-based identifier reveals nothing either. Only formats that deliberately embed a clock reading can be decoded this way.
If extraction returns something implausible, the id is probably one of those rather than a malformed Snowflake.