What Unix time is
Unix time (also called epoch time or POSIX time) counts the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970 (the "Unix epoch"), not counting leap seconds. It's the timestamp format used throughout Unix-like systems, most databases, and countless APIs — a single number that unambiguously identifies a moment in time without needing to specify a timezone.
How to convert a Unix timestamp
A Unix timestamp in seconds represents the number of seconds since 1970-01-01 00:00:00 UTC. To convert it to a date: if you're working in JavaScript, multiply a seconds-based value by 1,000 before passing it to Date (which expects milliseconds); a millisecond timestamp can be used directly. Microsecond and nanosecond values just use correspondingly finer scales of the same idea. To convert a date back to epoch time, interpret the date as a specific instant and express that instant as a count of seconds, milliseconds, microseconds, or nanoseconds since the Unix epoch. For example, the Unix timestamp 1700000000 (seconds) converts to 2023-11-14T22:13:20Z in UTC — paste either value into the tool above to see the full conversion both ways.
Seconds, milliseconds, microseconds, nanoseconds
The core definition of Unix time is in seconds, but many systems store it with finer precision — JavaScript's own Date.now() returns milliseconds, for example, and some databases and logging systems use microsecond or nanosecond precision. Since these are all just "the same kind of number at a different scale," this tool guesses the most plausible unit from the magnitude of the value you paste in — but that's genuinely a guess, not something it can know for certain. A 13-digit number is far more likely to be milliseconds than seconds (which would put it thousands of years in the future), but there's no way to be completely sure without more context. Use the Unit dropdown to override the guess if it picks the wrong one.
Unix time and leap seconds
Unix time is explicitly defined to have exactly 86,400 seconds in every day — it does not count leap seconds at all. When an actual leap second is inserted into UTC, most systems either repeat a second or "smear" it gradually across surrounding time, rather than the Unix timestamp itself ever representing a 61-second minute. A 2022 CGPM (General Conference on Weights and Measures) resolution decided that the permitted UT1−UTC difference will be increased by or before 2035, a change intended to make UTC effectively continuous and eliminate the practical need for regular leap-second insertions for at least a century. This is a common point of confusion: Unix time is not a pure count of elapsed physical seconds since 1970 when leap seconds are involved, even though it's defined and used as if it were.
Frequently asked questions
Does every timestamp on this page use UTC?
The ISO 8601, RFC 5322, and day of week fields are always shown in UTC specifically, since that's the one timezone this tool can always compute consistently without depending on the browser's own timezone database behaving a particular way. The separate local time field uses your browser's own detected timezone (via the standard Intl API), so it reflects whatever your device is actually configured to.
Why does converting a date without a timezone assume UTC?
A date-time string with no explicit offset is genuinely ambiguous — there's no single universally correct way to interpret it. This tool interprets it as UTC (rather than, say, silently assuming your browser's local timezone), since that gives a consistent, reproducible result regardless of who's using the tool or where. If you need a different timezone, include an explicit offset (e.g. +05:00) in what you paste in.
What's the largest or smallest timestamp this tool can handle?
This tool is bounded by what a JavaScript Date can represent at all: roughly year −271,821 to year +275,760. That full range applies when converting a numeric epoch value (Epoch → Date) — negative timestamps (dates before 1970) work correctly within it, and values outside it are rejected with a specific error rather than silently producing a wrong or garbled result. The Date → Epoch direction is narrower: it accepts a standard 4-digit year, so it doesn't parse ISO 8601's own extended year notation (e.g. a signed 6-digit year) for dates far enough in the future or past to need one — paste the equivalent epoch value instead if you need to go that far.
Sources
- IEEE Std 1003.1 (POSIX) — Seconds Since the Epoch
- RFC 3339 — Date and Time on the Internet: Timestamps
- RFC 5322 §3.3 — Date and Time Specification (the format commonly called "RFC 2822")
Last reviewed: . All conversion happens locally in your browser using the standard JavaScript Date and Intl APIs — nothing is uploaded.