Timestamp Converter

What this tool does

This tool converts a date or timestamp between four formats — Unix seconds, Unix milliseconds, ISO 8601 and RFC 2822 — showing all four representations at once for whichever value you enter. Pick the format your input is already in, and the other three are computed from it.

When you need it

• Turning a raw Unix timestamp from a log line, database column or API response into a human-readable date.
• Converting a human-entered date into epoch time for a system, script or API that expects a numeric timestamp.
• Catching a seconds-versus-milliseconds mismatch — a very common bug where a timestamp is off by a factor of exactly 1,000.
• Translating between ISO 8601 (used by most modern APIs and databases) and RFC 2822 (used in email headers and some older HTTP contexts) for a specific value.

Unix seconds versus Unix milliseconds

Unix (epoch) time is conventionally the number of seconds elapsed since January 1, 1970 UTC. Many systems follow that convention, but JavaScript's own Date.now() and a large share of JSON APIs report time in milliseconds instead. Feeding a millisecond value into a system expecting seconds (or vice versa) produces a timestamp off by roughly a thousandfold — dates that land in either 1970 or the far future are the classic symptom. Selecting the correct input format here avoids reproducing that mistake by hand.

Why the outputs are always UTC

ISO 8601 and RFC 2822 both support explicit time zone offsets, but this tool normalizes every output to UTC rather than trying to guess or preserve a time zone from the input. That keeps the four representations directly comparable to each other and makes the result reproducible regardless of where or when you run the conversion — a Unix timestamp has no time zone of its own, so anchoring every output format to UTC is the only choice that doesn't introduce ambiguity.

Why there's no "use current time" button

A timestamp converter that defaults to "now" would produce a different result every time the page loads, which defeats the purpose of a tool meant to give a specific, checkable answer. This tool always converts the exact value you provide — copy the current timestamp from wherever you're working (your terminal, your browser console, the system you're debugging) and paste it in if that's what you need converted.

Limits

The two Unix formats accept a plain number (a decimal point and an exponent such as 1e9 are allowed; hex like 0x10 is not). A seconds value larger than 10^11 is refused with a hint to switch to milliseconds, because it would land past the year 5000.

ISO 8601 input must be YYYY-MM-DD (read as midnight UTC) or a full date and time with an explicit offset, Z or ±hh:mm, such as 2026-09-25T14:30:00+02:00. A time with no offset is rejected on purpose: browsers would read it in the visitor's local time zone, so the same input would give different answers on different machines. RFC 2822 input must include a numeric or named zone (+0200, GMT, EST). Impossible calendar dates such as 30 February are rejected, not rolled into March, and free-form text such as Sep 25 2026 is refused rather than guessed at.

The RFC 2822 output is written with a numeric +0000 zone, as the standard requires when generating a date; the HTTP-style GMT suffix is accepted on input only. Note that RFC 2822 was later updated by RFC 5322, which keeps the same date format.