Timestamp Converter

What Unix time is

Unix time counts seconds since midnight UTC on January 1, 1970, the "epoch." It's the number nearly every computer system uses internally to represent a moment, because a single integer is trivial to store, compare, and sort compared to a formatted date string. When you see a raw number like 1700000000 in a database column, an API response, or a log line, that's almost always Unix time.

The epoch itself is arbitrary, 1970 isn't special, it's just the convention Unix picked and everything since has inherited. What matters is that it's a fixed, unambiguous reference point: everyone counting seconds from the same instant means every system can agree on what a given number means, at least once you know the resolution it was measured in.

Seconds vs milliseconds vs microseconds

That last part, the resolution, is where most timestamp bugs actually come from. Unix time doesn't have to be measured in seconds; a lot of systems, JavaScript's Date.now() among them, use milliseconds instead, and some logging and tracing systems go finer still, to microseconds or nanoseconds. Feed a millisecond timestamp into something expecting seconds and you don't get an error, you get a wildly wrong date, usually sometime in the 1970s.

There's a shortcut that gets you most of the way to the right answer without any tooling: count the digits. A 10-digit number is almost always seconds (roughly 2001 through 2286), 13 digits is milliseconds, 16 is microseconds, and 19 is nanoseconds; each level of precision tacks on 3 more digits, because each is 1000x finer than the last. This tool automates that check for you, and flags it when a reading resolves to an implausible date, like a 16-digit number landing in the year 5000, so you don't have to spot that by eye.

1700000000            → 10 digits → seconds
1700000000000         → 13 digits → milliseconds
1700000000000000      → 16 digits → microseconds
1700000000000000000   → 19 digits → nanoseconds

Timezones, UTC, and offsets

A Unix timestamp itself has no timezone, it's a count of seconds since a fixed instant, the same instant everywhere on Earth. Timezone only enters the picture when you turn that instant into a human-readable date and time, because "3pm" means something different in Tokyo than it does in New York. UTC (Coordinated Universal Time) is the timezone-free reference most systems display in internally; everything else is UTC plus or minus an offset.

That's why "just store everything in UTC" is close to universal advice for backend systems: a UTC timestamp is unambiguous no matter where the server or the reader is, and you convert to a local display only at the very last step, in the UI. Converting too early, or mixing local time into stored data, is a common source of off-by-a-few-hours bugs, especially around daylight saving transitions.

The Y2038 problem

Plenty of older and embedded systems store Unix time as a signed 32-bit integer. A signed 32-bit integer maxes out at 2,147,483,647, which corresponds to 03:14:07 UTC on January 19, 2038. One second past that, the count overflows and wraps around to a negative number, which typically gets interpreted as a date in December 1901. It's the spiritual successor to Y2K, real, well understood, and already fixed in most modern software (64-bit time_t, or timestamps in milliseconds, both push the boundary far into the future), but it still lurks in older systems and embedded devices. This tool flags it, quietly, whenever a resolved date lands at or past that boundary.

The universal inspector: what else has a timestamp hiding in it

A lot of identifiers you run into aren't timestamps on their surface but have one embedded. A UUID v1 packs a 60-bit timestamp into its first three fields (decoded here using the same logic as the UUID Generator's inspector). A UUID v7 does something similar with a plain 48-bit millisecond timestamp up front, which is exactly what makes v7 IDs sortable by creation time. A JWT's payload commonly carries iat (issued at), exp (expiry), and nbf (not before) as Unix-seconds claims. And a Snowflake ID, the kind Twitter/X and Discord use for post and message IDs, encodes a millisecond timestamp in its high bits relative to that platform's own custom epoch, extracted with a bit shift rather than a divide.

The paste box on this page tries all of these in turn, so you don't need to know in advance what you're holding, just paste it and see what comes back.