Epoch & Unix timestamp converter

Seconds, milliseconds, or nanoseconds? How to tell

A Unix timestamp is just a count of how long since midnight UTC on 1 January 1970, but the unit changes the magnitude by orders of magnitude, and nothing in the number itself labels which one you have. The reliable tell is the digit count for any timestamp in the current era. Ten digits is seconds (we are at roughly 1.76 billion). Thirteen digits is milliseconds. Sixteen is microseconds, and nineteen is nanoseconds. This tool counts the digits for you and picks the unit automatically, but the rule of thumb is worth memorising: if a date comes out in 1970, you probably fed seconds into a milliseconds field, or vice versa, and you are off by a factor of a thousand.

Languages disagree by default. JavaScript's Date.now() returns milliseconds; Python's time.time() returns floating-point seconds; Go's UnixNano() returns nanoseconds; Postgres extract(epoch ...) returns seconds. When two systems disagree about the unit, you get the classic thousand-fold or million-fold offset. Convert both ends here and the mismatch is obvious.

Snowflake IDs hide a timestamp

Twitter (now X), Discord, Instagram, and several other large systems generate IDs called snowflakes: 64-bit integers whose top 41 bits are a millisecond timestamp, followed by worker and sequence bits. That design means the ID is roughly sortable by creation time and carries its own birth certificate. To extract it you shift the ID right by 22 bits and add the service's custom epoch, Twitter's is 1288834974657 (4 November 2010). Paste any 18-to-19-digit ID above and this tool recognises it as a snowflake, decodes the embedded millisecond timestamp, and shows you when the object was created.

Discord uses the same layout with a different epoch (1 January 2015), so a raw Discord snowflake decoded against the Twitter epoch lands a few years early. For Twitter and X content the decode is exact.

The Year 2038 problem in one paragraph

Systems that store the seconds count in a signed 32-bit integer can only reach 2,147,483,647, which arrives at 03:14:07 UTC on 19 January 2038. One second later the counter overflows to a large negative number and the date wraps to December 1901. The fix is already widespread: 64-bit time types push the ceiling roughly 292 billion years out. But legacy embedded systems, old file formats, and database columns typed as 32-bit integers still carry the risk, which is exactly why it pays to convert and sanity-check a timestamp rather than trust it blind.

Need the human side of a date instead of the machine side? The time zone converter handles multi-city scheduling, and the JWT decoder reads the exp and iat epoch claims inside a token against your clock.