Timestamp Converter

Timestamp Converter

Convert Unix timestamps to human-readable dates and vice versa. Support for milliseconds, seconds, ISO 8601, RFC 2822 formats. Free epoch converter online

Unix timestamps are a single integer counting seconds (or milliseconds, or microseconds — your bug is probably here) since 1970-01-01 UTC. The moment two systems disagree on units, your "yesterday" becomes "the year 51,000" or "1970 plus a few seconds". This converter handles seconds, milliseconds, microseconds, and nanoseconds, displays the result in multiple timezones simultaneously, and decodes ISO 8601 strings back to their numeric form.

Seconds vs milliseconds: the #1 bug

Unix timestamps in seconds are 10 digits long for dates between 2001 and 2286 (1000000000 to 9999999999). Millisecond timestamps are 13 digits in the same date range. If your timestamp is 10 digits, it is almost certainly seconds. If it is 13, it is almost certainly milliseconds. If it is 16, microseconds. Mixing them silently produces dates that are off by a factor of 1000.

JavaScript Date constructors expect milliseconds. Unix command-line tools and most database fields use seconds. JWTs use seconds (per RFC 7519 §2). Java's Instant.now() returns nanoseconds via getNano() but milliseconds via toEpochMilli(). Always check the unit before doing arithmetic.

Working example

Input

1735689600

Output

Unit detected: seconds (10 digits)

UTC:           Wed, 01 Jan 2025 00:00:00 GMT
ISO 8601:      2025-01-01T00:00:00.000Z
Local (CET):   2025-01-01 01:00:00 +01:00
Relative:      4 months ago (from 2026-05-14)
Weekday:       Wednesday
Day of year:   1
Week number:   1 (ISO 8601)
Unix (ms):     1735689600000

If you accidentally interpreted the same value as milliseconds, you would get 1970-01-21 01:48:09 UTC — about 20 days into 1970. That mismatch is the giveaway.

Timezone gotchas

  • A Unix timestamp is always UTC. It is not "in a timezone" — display formatting picks the timezone, the timestamp itself has none.
  • Daylight saving time is invisible at the timestamp level. The numeric value is monotonic across DST transitions; only the local-time formatting jumps.
  • 2038 problem: 32-bit signed seconds-since-epoch overflows on 2038-01-19 03:14:07 UTC. Anything storing timestamps in INT or int32 will overflow then. Use BIGINT/int64 or stop using 32-bit time.
  • Java's default Date.toString() formats in the local JVM timezone, which is a common source of "works locally, fails in production" bugs. Always specify UTC explicitly when serializing.

When to reach for this tool

  • A log line contains 1735689600 and you need to know what that maps to without firing up a Python REPL.
  • A JWT's exp claim is in the past and you want to confirm by exactly how much.
  • You are auditing a database where some rows use seconds and some use milliseconds and you need a quick way to tell which is which.
  • You are constructing a URL with a Unix timestamp parameter and want to verify it points to the date you intended.

What this tool will not do

  • It will not convert to-or-from non-Gregorian calendars (Buddhist, Hijri, Hebrew). Those require dedicated libraries with regularly-updated rule tables.
  • It will not handle leap seconds. Unix time treats every day as exactly 86400 seconds; the actual ~27 leap seconds inserted since 1972 are smeared or ignored depending on system. For most use cases this does not matter, but for high-precision astronomy or financial timestamping it does.
  • It will not represent dates before 1970 unless you use negative timestamps. Some systems explicitly reject negatives — check before storing.

Frequently asked questions

How do I get the current Unix timestamp in JavaScript?

For milliseconds: Date.now(). For seconds: Math.floor(Date.now() / 1000). The floor matters — anything that expects integer seconds (JWT exp, most APIs) will misbehave with a fractional value.

Why does my date display "1970-01-01" in production?

You stored 0 or null somewhere that should have held a timestamp, and the formatting layer interpreted it as the epoch. Look for unset defaults in your ORM or schema definition.

How does this tool know if my input is seconds or milliseconds?

Heuristic: integers under 10^11 are treated as seconds, 10^11 to 10^14 as milliseconds, larger as microseconds or nanoseconds. The heuristic is reliable for dates between roughly 1973 and 5138 — outside that range, specify the unit manually.

What is the difference between ISO 8601 and RFC 3339?

RFC 3339 is a stricter subset of ISO 8601. RFC 3339 requires a timezone designator (Z or ±HH:MM), uses T as the date-time separator, and disallows shorthands like 2025-W23 (week-based date). For API design, prefer RFC 3339 — every parser handles it consistently.

Can I store a timestamp as a JSON number, or should I use a string?

Number is more compact and avoids parse errors, but loses precision past 2^53 milliseconds (year 287396) and is opaque to humans reading the JSON. Most APIs use ISO 8601 strings for human-readability at the cost of a few bytes. Pick one and document it.

Why does Math.floor(Date.now() / 1000) sometimes equal the previous second?

Because Date.now() returns milliseconds and you are losing the sub-second portion. Two calls 0.1s apart can return the same floor value. For accurate event timing, store milliseconds or microseconds, not floored seconds.

Related tools

Published · Updated · E-Utils editorial team