Snowflake ID → timestamp converter

How a Snowflake ID encodes time

A Snowflake ID is a 64-bit integer whose most significant bits are a millisecond timestamp measured from a service-specific epoch. In the original Twitter layout — kept by Discord — the top 41 bits are milliseconds since the epoch, followed by 10 bits of worker/process ID and a 12-bit per-millisecond sequence, so the timestamp is simply id >> 22 plus the epoch. The epochs differ: Twitter/X counts from 4 November 2010, Discord from 1 January 2015. Instagram shifts by 23 bits over its own 2011 epoch, and Mastodon simply uses Unix milliseconds shifted 16 bits. Pick the service above — the same digits decode to very different dates under the wrong epoch. Because the timestamp sits in the high bits, snowflakes sort roughly by creation time, which is why a tweet or Discord message ID doubles as a creation date. Within one millisecond the order follows the worker and sequence bits, and IDs from different workers are only as well ordered as those machines' clocks.

Querying and filtering by snowflake range

The min snowflake for an instant is the timestamp with worker and sequence bits all zero; the max has them all one. Any real ID created at that instant lies between the two, so the pair works as inclusive BETWEEN bounds in a database keyed by snowflakes, and the min value alone is the standard way to build a Discord search cursor: pass it as before/after to page through messages by date. To timestamp a snowflake in code, shift right by the variant's bit count and add its epoch — the decoder above shows the formula it used for the selected service.