Snowflake ID Timestamp

A snowflake is a 64-bit identifier that carries its own creation time. Paste a Discord or X (formerly Twitter) ID here and the converter extracts the embedded millisecond timestamp, showing what the ID means under each platform's epoch. Pick a calendar date instead and it builds the first snowflake of that day, which is the value you need when paging an API by time rather than by cursor.

What is inside a snowflake

The design comes from a distributed ID generator originally built at Twitter and later adopted by Discord and others. The goal was to produce unique, roughly sortable identifiers without a central coordinator. The solution packs several fields into a single 64-bit integer: the top 42 bits hold milliseconds elapsed since a chosen epoch, the next bits identify the machine and process that generated the ID, and the lowest twelve bits hold a per-millisecond sequence counter.

Because the timestamp occupies the highest bits, sorting IDs numerically sorts them approximately by creation time. That property is the whole point of the design, and it is why these IDs are long numbers rather than random strings.

Extracting the timestamp

Shift the ID right by twenty-two bits to drop the machine and sequence fields, then add the platform's epoch in milliseconds. The result is a standard Unix millisecond timestamp you can render as a date. The arithmetic is simple, but it must be done with 64-bit integers: a snowflake exceeds the range where floating-point numbers hold every integer exactly, so naive division in a language with only double-precision numbers silently loses the last few digits. This tool uses arbitrary-precision integer arithmetic to avoid that failure.

Two epochs, two answers

Discord counts from the first instant of 2015. X counts from a moment in late 2010 chosen when the original generator was deployed. The same numeric ID therefore decodes to two different dates depending on which platform produced it, separated by roughly four years. The converter shows both readings and marks the one that falls outside a plausible range, so an ID that produces a date before the platform existed is easy to spot.

If you know the source, take the matching row. If you do not, the plausible-range hint usually settles it: only one interpretation typically lands in a period when that platform was operating.

Building a snowflake from a date

Running the conversion backwards produces the smallest possible ID for a given instant, with the machine and sequence fields set to zero. That synthetic value is not a real identifier of any object, but it is extremely useful as a boundary. Platform APIs that accept before and after parameters compare them numerically against real IDs, so a synthetic snowflake built from a date acts as a precise time filter — useful for fetching messages from a specific week or paging through a backlog in chronological chunks.

Because the tool builds the ID from midnight UTC, remember to account for your own zone if you are targeting a local calendar day. The time zone converter helps translate that boundary.

Reading the machine and sequence fields

The worker and process values identify which generator produced the ID, and the increment is a counter that resets each millisecond. These fields are mostly of interest when debugging a distributed system of your own, where a stuck counter or a duplicated worker number signals a configuration problem. For ordinary use they are trivia. They do reveal one thing worth knowing: a burst of IDs created in the same millisecond will differ only in the increment, so consecutive IDs from a busy service are not evenly spaced in time.

Precision and what the timestamp actually means

The embedded time records when the ID was generated, which is normally when the object was created on the server. It is not an edit time, a scheduled publication time, or the moment a client pressed send. For most purposes the difference is milliseconds and irrelevant, but in forensic or audit contexts the distinction matters: the snowflake tells you when the server minted the identifier, nothing more.

Timestamps are recorded in UTC. Any local time you see elsewhere in a client interface is a display conversion applied afterward.

Common uses

Moderators check when an account or message was created without relying on displayed dates. Developers debug API pagination and confirm that a cursor points where they expect. Researchers date archived content that survives only as an ID. Support teams verify whether a report refers to a recent event or an old one. In each case the ID itself is the evidence, and it works even when the original object has been deleted.

Related timestamp tools

Once you have the millisecond value, the Unix timestamp converter handles further formatting, and the batch converter processes a whole list at once. For the Discord message markup that renders a live timestamp in chat, use the Discord timestamp generator, which produces the angle-bracket codes rather than decoding IDs. Other platform-specific epochs are covered by the WebKit and Cocoa converters, and the complete list lives on the converters hub.

Sanity-checking a result

A believable snowflake for a recent object has seventeen to nineteen digits. Far shorter values decode to dates near the epoch, which usually means you pasted a partial ID or a different kind of identifier entirely. If the decoded date lands in the future, check for stray characters or a copied thousands separator. And if both epoch readings look implausible, the number probably is not a snowflake at all — plenty of systems use long numeric IDs that carry no timestamp.