Timestamp Converter

Where timestamps show up

Unix time is the lingua franca of computers. API responses carry created_at and expires_at fields as epoch numbers; log files prefix every line with one; database columns store them because they sort, compare and index beautifully; JWT tokens express their exp and iat claims in seconds since the epoch; cron systems, cache TTLs, analytics events and file metadata all speak the same numeric language. Anywhere a machine needs to record "when" without ambiguity about format, locale or timezone, an epoch number appears.

The catch is that 1735689600 means nothing to a human glancing at a log at 2 a.m. Converting between that number and an actual date — in the right timezone — is one of the most repeated micro-tasks in software work, which is exactly why this page exists. The reverse trip matters just as much: scheduling a job, setting an expiry or writing a test fixture all require turning a human date back into the number the machine expects.

Seconds vs milliseconds: the classic trap

Unix time is defined in seconds, but JavaScript's Date.now() and many Java and C# APIs work in milliseconds. Mixing the two produces spectacular errors: read a 13-digit millisecond value as seconds and your date lands roughly 55,000 years in the future; read a 10-digit seconds value as milliseconds and everything happened in January 1970, a few hours after the epoch.

The reliable rule of thumb is digit count: around 10 digits is seconds (valid until the year 2286), 13 digits is milliseconds, 16 or more is microseconds or nanoseconds. This converter auto-detects the unit from the length of your input and tells you which one it picked, with a manual override when you know better.

Choosing the right unit for your stack

Every ecosystem picked a side in the seconds-versus-milliseconds debate, and knowing yours saves real debugging time. JavaScript is milliseconds: Date.now() returns 13 digits, and new Date(1735689600000) takes milliseconds too. Python is seconds — time.time() returns a float like 1735689600.0 — though datetime.timestamp() follows the same convention. Java splits the difference: System.currentTimeMillis() is milliseconds, while the modern java.time.Instant.getEpochSecond() is seconds. Go offers time.Now().Unix() in seconds, .UnixMilli() in milliseconds, and .UnixNano() in nanoseconds.

Databases add their own wrinkles: MySQL's UNIX_TIMESTAMP() returns seconds, PostgreSQL's EXTRACT(EPOCH FROM ...) returns seconds with fractional precision, and MongoDB's Date stores milliseconds internally. When two systems disagree about a date by exactly a factor of one thousand, unit mismatch is almost always the culprit — paste the suspicious number into the left panel and the auto-detection will tell you which unit it actually is.

Timezones, UTC and honest caveats

A timestamp itself carries no timezone — it is an absolute instant defined against UTC. Timezones only enter the picture when the instant is displayed: 1735689600 is 00:00 in London, 19:00 the previous evening in New York and 09:00 in Sydney. When comparing against documentation or a colleague's screenshot, always anchor on the UTC rendering.

Daylight saving time adds one more wrinkle to display. When clocks spring forward, one wall-clock hour simply does not exist; when they fall back, one hour happens twice. The timestamp itself glides through both events untouched — only the local rendering jumps. This converter's timezone math follows the IANA tz database used by your browser, so DST transitions, historical offset changes and half-hour zones like India's UTC+5:30 all render correctly.

Two honest footnotes. Leap seconds: Unix time officially ignores them, so rare 23:59:60 moments can be off by a second between systems — irrelevant for almost all applications. And the year-2038 problem: systems storing epoch seconds in signed 32-bit integers overflow on January 19, 2038. Any modern 64-bit system, including this tool, is unaffected.