Snowflake ID & Date Converter

Every ID on Discord - users, messages, channels, servers, roles, attachments - is a snowflake: a 64-bit integer that encodes when it was created. Discord borrowed the format from Twitter, and the useful consequence is that an ID is also a timestamp. You do not need to ask an API when something was made, because the answer is already sitting inside the number.

The 64 bits are divided into four fields. The top 42 bits are milliseconds since the Discord epoch, which is 1 January 2015 at midnight UTC (1420070400000 in Unix milliseconds). The next 5 bits are the internal worker ID, the 5 after that are the process ID, and the bottom 12 are a per-process counter that increments for each ID generated in the same millisecond.

To read the timestamp you shift the number right by 22 bits to discard the worker, process and counter fields, then add the Discord epoch. In JavaScript that is `Number(BigInt(id) >> 22n) + 1420070400000`. The BigInt matters: a snowflake exceeds Number.MAX_SAFE_INTEGER, so doing this with ordinary numbers silently loses precision and gives you a timestamp that is close but wrong.

The bottom 12 bits allow 4,096 IDs per process per millisecond. Because the worker and process fields sit between the timestamp and the counter, two IDs generated in the same millisecond by different workers do not sort in generation order relative to each other - they sort by worker ID first.

In practice this rarely matters, because a millisecond is a long time and Discord's ordering guarantees are per-channel rather than global. But it does mean you should not treat a snowflake as a strict global sequence number. If you need to know which of two near-simultaneous messages came first, the channel's own ordering is authoritative, not the raw integer comparison.

Account age checks are the most common. Because the creation time is embedded in the user ID, you can tell how old an account is without any API call - which is why raid protection bots reject accounts created in the last few hours. They are reading the snowflake, not querying Discord.

It is also useful for auditing. If you are investigating when a channel was created or when a specific message was posted and you only have a copied ID, converting it gives you an exact UTC timestamp to work from. And because the epoch is fixed, an ID converted today gives the same answer as one converted in five years.

The conversion is simple: shift the ID right 22 bits to drop the worker, process and increment fields, then add 1420070400000, which is Discord's epoch in Unix milliseconds. The resulting number is the exact timestamp in milliseconds.

If you have an ID like 936929561302675456, dividing by 2^22 and adding the epoch gives you a human-readable date like October 20, 2020 at 08:29:52 UTC.

Bot developers use snowflake ranges to query all messages or users created in a specific time window. Moderators check the age of accounts involved in a raid. Archivists date channels and messages without calling the API for every single item.

Unlike random UUIDs or auto-incrementing database IDs, snowflakes are sortable by time without any external data. This is why Discord never reveals a separate created_at field for most objects; the ID itself carries that information. Twitter pioneered this format in 2010, and Discord adopted it in 2015 with a custom epoch.

Discord uses the middle bits to route ID generation across its internal systems, so the worker and process values can help identify which part of Discord's infrastructure created a given object. For most users these are just trivia, but they confirm the internal distribution of ID generation.