Snowflake IDs, ISO Weeks & Timestamp Math: Beyond Basic Epoch Conversion

Q: How do I get the creation date out of a Discord or Twitter/X ID?

Those platforms use 'snowflake' IDs, which embed a timestamp left-shifted 22 bits on top of a fixed platform epoch (Discord: 1420070400000, Twitter/X: 1288834974657). A snowflake decoder mini-tool reverses that bit-shift with the correct platform epoch to recover the exact creation date-time, entirely client-side.

Decoding a snowflake ID's hidden timestamp

Short answerA snowflake ID (used by Discord, Twitter/X, and similar platforms) is a large integer that packs a creation timestamp into its high bits, shifted 22 places to the left, on top of a fixed platform-specific epoch. Shift it back and subtract the epoch, and you get the exact creation date-time.

Say a support ticket references a Discord message ID like 175928847299117063 — a number with no obvious date attached. Right-shifting that integer by 22 bits and adding Discord's custom epoch (1420070400000, itself a millisecond Unix timestamp for January 1, 2015) recovers the exact millisecond the message was created. Twitter/X snowflakes work the same way with a different fixed epoch (1288834974657).

Because the numbers involved exceed what JavaScript can safely handle as a regular Number, this kind of decoding needs BigInt arithmetic rather than plain floating-point math — a detail that trips up quick one-off scripts. A snowflake decoder mini-tool handles that bit-shifting and platform-epoch lookup for you: paste the ID, pick Discord or Twitter/X, and read off the creation date.

Why platforms do thisEmbedding a timestamp in the ID itself means IDs are roughly sortable by creation time without a separate database column or index — useful at the scale these platforms operate at.

Why ISO week numbers matter

Short answerThe ISO week number (ISO 8601) labels each week of the year 1 through 52 or 53, always starting on a Monday, with week 1 defined as whichever week contains the year's first Thursday. It's a cleaner way to talk about "which week" than a calendar date range when weeks matter more than exact days.

Suppose (hypothetically) a factory schedules production runs by week, or a finance team closes the books "by week 30" rather than by a specific date range — ISO week numbers avoid ambiguity that a plain "week of July 21" description can carry across different calendars and locales. Because ISO weeks don't line up cleanly with month boundaries, the first and last week of a year sometimes technically belongs to the adjacent calendar year, which is exactly the kind of edge case that's easy to get wrong by hand and worth letting a converter compute for you alongside the day-of-week and day-of-year breakdown.

Building SQL-ready date ranges

Short answerTo filter database rows by "a day," "a month," or "a year," you need the epoch for the exact start (00:00:00) and end (23:59:59) of that period — not just the date itself. A date-range mini tool generates both values, in seconds and milliseconds, for local time or UTC.

A query like WHERE created_at BETWEEN 1735689600 AND 1735775999 is far less error-prone to write than manually computing "midnight on this date" and "one second before midnight the next day" by hand, especially once a timezone or daylight-saving transition is involved. Picking a scope of day, month, or year and letting the tool emit both boundary epochs removes an entire category of off-by-one-day bugs from log filtering and reporting queries.

Scope (example)	Start epoch (UTC)	End epoch (UTC)
Day: 2026-07-29	1785283200	1785369599
Month: July 2026	1782892800	1785369599

Illustrative values for the day/month scope shown above; always regenerate the actual figures for your own timezone and date rather than reusing these.

What about UUIDv7 and ULID?

Not built yet — noted for context. The Unix Timestamp Converter currently decodes epoch values and Discord/Twitter-X snowflake IDs. It does not yet parse UUIDv7 or ULID identifiers. This section describes the idea, not a shipped feature.

Snowflake IDs aren't the only identifier format with a timestamp baked in. UUIDv7, a newer UUID variant designed for database primary keys, stores a 48-bit millisecond Unix timestamp in its first six bytes so that UUIDs generated later sort after ones generated earlier — a property classic random UUIDv4 doesn't have. ULID (Universally Unique Lexicographically sortable Identifier) does something similar with a Crockford base32-encoded timestamp in its first 10 characters.

If you're debugging why rows in a UUIDv7-keyed table appear in a certain order, or trying to figure out roughly when a ULID-tagged record was created, you currently have to decode the bit layout (for UUIDv7) or the base32 encoding (for ULID) by hand or with a separate script. A dedicated UUIDv7 / ULID timestamp extractor mini-tool — paste the identifier, get back the embedded creation date-time — would be a natural companion to the existing snowflake decoder, since the underlying idea (timestamp bits embedded in a sortable ID) is the same even though the encoding differs. It's a reasonable feature to expect in a future update to this tool, alongside the epoch and snowflake conversions that already exist.

Convert epoch seconds/milliseconds to a date (or back), decode Discord/Twitter-X snowflake IDs, get ISO week numbers, and generate SQL-ready date ranges — all in your browser.

Try the free Unix Timestamp Converter →

Frequently asked questions

How do I get the creation date out of a Discord or Twitter/X ID?

Those platforms use "snowflake" IDs, which embed a timestamp left-shifted 22 bits on top of a fixed platform epoch (Discord: 1420070400000, Twitter/X: 1288834974657). A snowflake decoder mini-tool reverses that bit-shift with the correct platform epoch to recover the exact creation date-time, entirely client-side.

What is an ISO week number and why would I need one?

The ISO week number (ISO 8601) numbers weeks 1 through 52 or 53 per year, with Monday as the first day of the week and week 1 defined as the week containing the year's first Thursday. It's commonly used in reporting, invoicing, and manufacturing schedules where "week 33" is more meaningful than a calendar date range.

How do I get a start-of-day and end-of-day epoch for a SQL query?

Pick a date and a scope (day, month, or year); a date-range mini tool computes the epoch for 00:00:00 and 23:59:59 of that period, in both seconds and milliseconds, in either local time or UTC. Those two values plug directly into a WHERE created_at BETWEEN start AND end clause without manual date math.

Do UUIDv7 and ULID also contain a timestamp like snowflake IDs?

Yes. UUIDv7 stores a 48-bit millisecond Unix timestamp in its first 6 bytes, and ULID encodes a similar millisecond timestamp in its leading 10 characters — both by design, so IDs sort roughly by creation time. Extracting that timestamp back out requires decoding the ID's specific bit layout or character encoding rather than a generic epoch parser.

Is there a single tool that decodes epoch, snowflake, and UUIDv7/ULID timestamps together?

A general epoch converter with a snowflake decoder covers Discord- and Twitter/X-style IDs today. A dedicated UUIDv7/ULID timestamp extractor is a distinct mini-tool idea — different bit layout, different base32/hex encoding — that would sit alongside the existing snowflake decoder as a natural next addition for anyone debugging modern database primary keys.

A note on this guide: epoch and date-range figures above are illustrative examples for explaining the underlying method, not live data; the UUIDv7/ULID extractor described here is a feature idea for a possible future update, not a currently available part of the tool. This article is informational and does not replace checking your own system or database documentation.