Unix timestamps and date formats explained
Computers usually store time as a single number: the seconds that have passed since 1 January 1970 at midnight UTC, known as the Unix epoch. That number is the same everywhere on Earth at the same instant, which makes it ideal for databases, logs and APIs. People, on the other hand, read dates in local time, in many formats and with daylight saving rules.
This converter takes whatever you paste, whether a Unix number, an ISO 8601 string, an email-style RFC 2822 date or plain English such as March 5 2025, and shows it in every common format at once, in the time zone you choose.
How to use it
- Paste a timestamp or date into the input box.
- The tool detects the kind of input: up to 10 digits are read as Unix seconds, 11 to 16 digits as Unix milliseconds, and anything else as a date string.
- Pick a time zone to see the local wall-clock time there.
- Copy any row: Unix seconds, milliseconds, ISO 8601, RFC 2822, local time, UTC or the relative phrase.
Example: a round Unix number
1700000000
Unix milliseconds: 1700000000000 ISO 8601 (UTC): 2023-11-14T22:13:20.000Z RFC 2822: Tue, 14 Nov 2023 22:13:20 GMT
One point seven billion seconds after the epoch fell on 14 November 2023. The milliseconds form is the same instant with three more digits, which is what JavaScript's Date.now() returns.
Seconds or milliseconds?
Unix tools, most databases, JWTs and many APIs use seconds. JavaScript, Java and a lot of browser analytics use milliseconds. Mixing them up is the most common timestamp bug: a seconds value read as milliseconds lands in January 1970, and a milliseconds value read as seconds lands tens of thousands of years in the future. A quick check is the length: today's timestamps have 10 digits in seconds and 13 in milliseconds.
ISO 8601, RFC 2822 and time zones
ISO 8601, as in 2023-11-14T22:13:20Z, is the format to use in APIs and files: it sorts correctly as text and the Z or offset at the end makes the time zone explicit. RFC 2822 is the format of email headers and some HTTP headers. A date string without any offset is ambiguous; this tool reads a bare date such as 2025-03-05 as midnight UTC.
Time zone names like Europe/Berlin or America/New_York come from the IANA database, which also records each zone's daylight saving history. Your browser supplies those rules, so the local time shown here matches what your operating system would show.
The year 2038 problem
Systems that store Unix time in a signed 32-bit integer can only count to 2,147,483,647, which is 19 January 2038 at 03:14:07 UTC. One second later the value overflows to a date in 1901. Modern systems use 64-bit time, but old embedded devices and file formats may still break, so it is worth testing dates beyond 2038 in software that will live that long.
Questions
Does a Unix timestamp include a time zone?
No. It always counts from midnight UTC on 1 January 1970, so it describes one instant everywhere. The time zone only matters when you turn it into a wall-clock time.
Does Unix time count leap seconds?
No. Every Unix day has exactly 86,400 seconds, so a leap second is not counted separately. For everyday work this makes no difference.
Can I convert dates before 1970?
Yes. Dates before the epoch are negative numbers; type a minus sign in front of the seconds.