Skip to tool
ecech.
Finance English Developer Text & SEO Network Time E-commerce Math Design Health YouTube Image Converters Home
💻 Developer & Code

Get the Creation Time Out of an ID Without Touching the Database

Snowflakes, ObjectIds, ULIDs and UUIDv7 all carry the time they were made. Paste one and read the date — with the right epoch, which is where this usually goes wrong.

Format

—

Created (UTC)

—

Your local time

—

Age

—

Structure

Advertisement

How the calculation works

What the 64 bits of a Snowflake are for 1 41 bits 10 bits 12 bits unused milliseconds since the epoch machine sequence Shift right 22 bits to drop machine and sequence, then add the platform's epoch. Use Twitter's epoch on a Discord ID and you are four years out, with no error.

How to Use This Tool

Paste an ID. The format is detected from its shape and the timestamp is extracted with the right arithmetic for that format.

The four formats

  • Snowflake — a 64-bit integer, usually 18 or 19 digits. The top 41 bits are milliseconds since a platform-specific epoch, then 10 bits identify the machine that generated it and 12 bits are a per-millisecond counter. Used by Twitter/X, Discord, Instagram and many internal systems.
  • MongoDB ObjectId — 24 hex characters. The first 8 are seconds since 1970, so the resolution is one second, not one millisecond. The rest is a random value plus a counter.
  • ULID — 26 characters in Crockford base32. The first 10 encode milliseconds since 1970 and the remaining 16 are random. Sorts chronologically as text, which is the point.
  • UUIDv7 — a standard UUID whose first 48 bits are milliseconds since 1970. Identifiable by the version digit 7 at the start of the third group.

The epoch trap

Snowflake IDs do not store an absolute time. They store a count from a starting point each platform chose, and those differ:

  • Twitter/X — 4 November 2010
  • Discord — 1 January 2015

Apply Twitter's epoch to a Discord ID and every date lands about four years early. Nothing errors, nothing looks impossible, and you get a plausible date that is simply wrong — the same failure pattern as reading milliseconds as seconds. If a decoded date is suspiciously close to some other significant date, check which epoch you used first.

How precisely each format dates a record ObjectId 1 second two records in the same second are indistinguishable by time Snowflake 1 millisecond plus a 12-bit counter within each millisecond ULID, UUIDv7 1 millisecond random tail, so ordering within a millisecond is arbitrary None of them is a clock. All of them are good enough to sort by.
Resolution decides whether "created before" is answerable for two nearby records.

What this is good for, and what it is not

It is genuinely useful for dating a record when you have the ID and not the row, checking whether two records were created around the same time, and sanity-checking imported data. It is also how you can tell roughly when a Discord account or a tweet was created from its link.

What it is not is authoritative. The timestamp is set by whichever machine generated the ID, from that machine's clock, so a skewed server produces skewed IDs. It also records when the ID was made, which is not always when the record was saved — an ID generated in advance and used later will read early. For anything that matters, the stored created_at column is the source of truth and this is a convenience.

Why IDs carry timestamps at all

Sortability. A distributed system cannot use an auto-incrementing counter without a central authority to hand out numbers, which becomes a bottleneck. Putting the time at the top of the ID means IDs generated on different machines still sort roughly chronologically, and roughly is enough for indexes to stay efficient. That is also why ULIDs and UUIDv7 exist — a random UUIDv4 scatters writes across a B-tree index, while a time-ordered one appends.

Advertisement

Frequently Asked Questions

How do I get the date from a Snowflake ID?
Shift the 64-bit integer right by 22 bits to discard the machine and sequence portions, then add the platform's epoch in milliseconds. Twitter/X uses 4 November 2010 and Discord uses 1 January 2015, so you need to know which platform the ID came from.
Why did my decoded Snowflake date come out wrong?
Almost certainly the wrong epoch. Snowflakes store a count from a platform-specific starting point, so applying Twitter's epoch to a Discord ID puts every date about four years early. Nothing errors and the result looks plausible, which is what makes the mistake persistent.
What timestamp does a MongoDB ObjectId contain?
The first 8 hex characters are seconds since 1 January 1970. The resolution is one second, not one millisecond, so two documents created in the same second carry the same embedded time and cannot be ordered by it — the remaining bytes are a random value and a counter, not a finer clock.
What is the difference between ULID and UUIDv7?
Both put milliseconds at the front so they sort chronologically. ULID is 26 characters of Crockford base32 and is not a UUID; UUIDv7 keeps the standard UUID format and layout, so it drops into any system that already expects a UUID. The timestamp semantics are the same.
Is the embedded timestamp reliable?
It reflects the clock of whichever machine generated the ID, so a skewed server produces skewed IDs. It also records when the ID was created, not necessarily when the record was saved. For anything consequential the stored created_at column is authoritative and this is a convenience.
Why do IDs contain timestamps at all?
So they sort. A distributed system cannot use a central auto-incrementing counter without creating a bottleneck, but putting the time at the top of the ID means IDs from different machines still order roughly chronologically. That also keeps database indexes appending rather than scattering, which is why UUIDv7 was introduced alongside random UUIDv4.
Does this send my ID anywhere?
No. It is pure arithmetic on the ID itself, done in your browser.

Related tools in Developer & Code

💻AI Latency BudgetFind the time left for inference after every non-model stage consumes its share. 💻Semantic Cache SavingsApply cache hit rate to the real difference between uncached and cached request cost. 💻Structured Retry CostConvert schema failures into token cost plus explicit manual handling. 💻AI Throughput TimeInclude queue delay and retry capacity instead of dividing tokens by a headline rate alone.
#developer #time #database
Browse all Developer & Code tools
The person who builds ecech., at the desk where the tools are written.

Made by one person

ecech. is not a content farm. Every tool here is written and checked by hand, one at a time, by someone who wanted the tool to exist and could not find a version that showed its working.

No accounts and no sign-in, and nothing you type reaches a server — every calculation on this page runs inside your browser. The ads are served by Google and do set their own cookies, which is set out in full on the privacy page. More about the site.