How to use the id timestamp decoder
- Paste one identifier per line: UUIDs, ULIDs, MongoDB ObjectIds, KSUIDs or long numeric snowflake ids.
- If you have numeric ids, choose whether they are Twitter or Discord snowflakes, or leave the choice open to see both.
- Read the table for the kind of each id and the time stored in it, in UTC.
- Use the Unix milliseconds column for sorting or to compare with log times, and download the table as a CSV.
Formula
UUID v7 and ULID: first 48 bits (ULID: first 10 base-32 characters) = Unix milliseconds
UUID v1 and v6: 100 ns ticks since 1582-10-15, time = ticks / 10,000 - 12,219,292,800,000 ms
ObjectId: first 4 bytes = Unix seconds. KSUID: first 4 bytes + 1,400,000,000 = Unix seconds
snowflake: (id shifted right by 22 bits) + epoch of the service, in ms
The epoch of a snowflake is 1,288,834,974,657 ms for Twitter and 1,420,070,400,000 ms for Discord. A numeric id can look valid under both, which is why the page shows both.
Six identifiers from different systems
The version 7 UUID 018f3b8e-5d2a-7c1e-9a4b-3f6d2e8c1b07 holds the time 2024-05-02 23:05:36.810 UTC. The version 1 UUID c232ab00-9414-11ec-b3c8-9f6bdeced846, the version 6 UUID 1EC9414C-232A-6B00-B3C8-9F6BDECED846 and the version 7 UUID 017F22E2-79B0-7CC3-98C4-DC0C0C07398F are the published test vectors, and all three decode to 2022-02-22 19:22:22.000 UTC.
The ULID 01ARZ3NDEKTSV4RRFFQ69G5FAV decodes to 2016-07-30 23:54:10.259 UTC and the ObjectId 507f1f77bcf86cd799439011 to 2012-10-17 21:13:27 UTC. The number 175928847299117063 decodes under the Discord epoch to 2016-04-30 11:18:25.796 UTC, the example Discord documents, while 1541815603606036480 reads as 2022-06-28 16:07:40.105 UTC for Twitter.
Why ids carry time
Time-ordered ids sort by creation time, which keeps database indexes compact and makes the newest records easy to find. Version 7 UUIDs and ULIDs put milliseconds first for that reason. Older version 1 UUIDs also embed a timestamp, but in a layout where the low bits come first, so they do not sort by time as text.
Random version 4 UUIDs and name-based versions 3 and 5 carry no time at all, and the page says so instead of showing a made-up date.
How far to trust the time
The time comes from the clock of whatever made the id, so a wrong clock or a deliberately set value gives a wrong time. An id can also be re-encoded or copied from elsewhere. Use the decoded time as a clue about when something was created, for debugging or sorting, and not as proof. To make ids, use the UUID Generator. To convert times, see the Unix Timestamp Converter and the Excel Date Serial Number Converter, and for format strings the Date Format String Translator.
Assumptions and limits
- Up to 500 lines are read at a time, one identifier per line. UUIDs may have braces, hyphens or a urn:uuid: prefix.
- Numeric ids of 15 to 20 digits are read as 64 bit snowflake ids. Shorter or longer numbers are not recognized.
- Times are shown in UTC. Ids are checked in your browser and are not sent anywhere.
- A 24 hex digit string is read as an ObjectId, and a 27 character base-62 string as a KSUID.
Frequently asked questions
Which UUID versions contain a time?
Versions 1, 6 and 7. Version 7 holds Unix milliseconds in its first 48 bits. Versions 1 and 6 hold a count of 100 nanosecond steps since October 15, 1582. Versions 3, 4, 5 and 8 hold no time.
Why does a numeric id show two different dates?
Snowflake ids from different services count milliseconds from different start dates. The same number gives a different date under each epoch. Choose the service to see only one, or use the date that makes sense for your data.
Can the decoder tell me who made an id?
No. It reads only the time, and for some kinds the worker or counter fields, which are shown in the detail for snowflakes. It does not look anything up.
What happens with ids it does not recognize?
The row is marked Not recognized, with no time, and the other rows are decoded as usual. Check for extra characters, spaces inside the id or a truncated copy.