Timestamp converter

What is a timestamp?

A timestamp represents a single point in time. Two formats dominate. Unix epoch time is a number — seconds (or sub-second units) elapsed since 1970-01-01T00:00:00Z. ISO 8601 / RFC 3339 is a human-readable string like 2026-05-08T14:30:00Z. Both refer to the same instant; they differ only in surface form.

Time looks easy and is not. Daylight saving, leap seconds, changing timezone databases, and the implicit assumptions of whoever designed your API all conspire to produce subtle bugs that surface at 2 a.m. on a Sunday in March.

How it works

Unix timestamps come in different units. Seconds are 10 digits today (around 1.7 billion). Milliseconds are 13 digits, microseconds 16, and nanoseconds 19. The difference is purely a multiplier — a 1000x error between seconds and milliseconds is the most common timestamp bug in the wild. JavaScript's Date.now() returns milliseconds; most other languages default to seconds.

ISO 8601 supports timezone offsets via +HH:MM or -HH:MM suffixes; the literal Z is shorthand for +00:00 (UTC). A string with no offset, such as 2026-05-08T14:30:00, is timezone-naive — its meaning depends entirely on whoever wrote it. RFC 3339 is the stricter Internet profile of ISO 8601 and is the format most modern APIs accept.

When to use this tool

• Comparing API request and response timestamps during integration debugging.
• Reading log lines that contain epoch numbers and translating them to a wall-clock time you can reason about.
• Checking certificate validity windows (notBefore, notAfter) or JWT exp/iat fields.
• Translating Unix mtime/ctime from stat output.
• Sanity-checking whether a timestamp is in seconds or milliseconds.

Common pitfalls

• Confusing seconds with milliseconds. A 13-digit value parsed as seconds resolves to roughly the year 33000; a 10-digit value parsed as milliseconds resolves to 1970.
• The Y2038 problem: a 32-bit signed second-counter overflows on 2038-01-19T03:14:07Z. Embedded systems still using int32_t time_t must migrate.
• Daylight saving transitions. In spring, one wall-clock hour does not exist. In fall, one wall-clock hour exists twice. Adding 24 hours to compute “tomorrow” can produce the wrong result.
• Timezone-naive strings. 2026-05-08T14:30:00 in two different timezones names two different moments up to 26 hours apart.
• Leap seconds are not part of Unix time. UTC inserts them occasionally; Unix pretends they do not exist.

Frequently asked

Why does my Unix timestamp show the year 1970?

You probably have milliseconds being parsed as seconds, or you have a zero or near-zero value. Check the digit count: 10 for seconds, 13 for milliseconds.

What is the difference between ISO 8601 and RFC 3339?

ISO 8601 is the broader standard with many optional shapes; RFC 3339 is a stricter profile of it for Internet protocols. Anything that is valid RFC 3339 is valid ISO 8601, but not the reverse. APIs almost always want RFC 3339.

How do I store dates without timezone bugs?

Always store either the Unix epoch (an absolute moment) or an RFC 3339 string with an explicit offset. Avoid timezone-naive strings in databases, files, and APIs.

What is the Y2038 problem?

On 2038-01-19T03:14:07Z, a signed 32-bit second-counter overflows from 2147483647 to a negative number, wrapping to 1901. Systems still using time_t as 32-bit will read wrong dates after that instant.