Unix timestamp converter

How to use

• Timestamp → date: paste a number (1700000000, 1700000000000…) or a date string. The unit is detected from the number of digits, but you can force seconds, milliseconds, microseconds or nanoseconds. Numbers copied from a spreadsheet work too (1.7E+12, 1,700,000,000). You get, all at once: ISO 8601 in UTC and in the chosen zone, RFC 2822, the long date, relative time ("3 hours ago"), day of week, ISO week, day of year and offset. Every line has a copy button.
• Date → timestamp: pick a date, time and seconds. They are read in the selected time zone and turned into a Unix timestamp in seconds and milliseconds.
• Batch: paste a whole column (from a log, spreadsheet or SQL query), one entry per line. Invalid lines are flagged and the result goes out as CSV or straight into a spreadsheet (TSV).
• The Now band shows the current timestamp, updated every second. Pause it, copy it in seconds or milliseconds, or send it to the converter.

Everything is computed in your browser: nothing you type leaves your device.

What Unix time is

Unix time (also called epoch time or POSIX time) counts the seconds elapsed since January 1, 1970, 00:00:00 UTC. It is a single number with no time zone, which is why it is the most common way to store "when something happened" in databases, logs, APIs and files.

Dates before 1970 are negative: -86400 is December 31, 1969, 00:00 UTC.

Unix time ignores leap seconds: every day has exactly 86,400 seconds. That keeps conversion simple and predictable, but it is not meant for second-accurate intervals spanning decades.

Seconds, milliseconds, microseconds or nanoseconds?

Each system uses its own unit, and mixing them up is the most common bug. Automatic detection uses the number of digits (for present-day dates):

• up to 10 digits = seconds (e.g. 1700000000): Unix/Linux, PHP time(), Python int(time.time()), JWT (exp, iat).
• 11 to 13 digits = milliseconds (e.g. 1700000000000): JavaScript Date.now(), Java System.currentTimeMillis().
• 14 to 16 digits = microseconds (e.g. 1700000000000000): Python time.time_ns() // 1000, ClickHouse DateTime64(6).
• 17 to 19 digits = nanoseconds (e.g. 1700000000000000000): Go UnixNano(), InfluxDB, OpenTelemetry.

If a date lands in January 1970, a value in seconds was almost certainly read as milliseconds (for example, new Date(1700000000) in JavaScript). If it lands in an absurd year like 55,000, the opposite happened.

UTC, time zone and offset are not the same thing

• UTC is the world reference. A Unix timestamp is always UTC.
• An offset is the difference from UTC at a given instant: -03:00, +05:30.
• A time zone (such as America/New_York) is the rule that says which offset applies on each date, including daylight saving time and historical changes. That's why the converter uses IANA names, not just offsets.

The same instant 1700000000 is 22:13 in UTC, 17:13 in New York and 03:43 the next day in New Delhi.

Daylight saving: the time that doesn't exist and the time that happens twice

When clocks spring forward, a range of wall-clock times simply doesn't exist that day. In New York, on March 10, 2024, clocks jumped from 01:59:59 to 03:00:00: there was no 02:30. When clocks fall back, a range repeats: on November 3, 2024, 01:30 happened twice (first at offset −04:00, then at −05:00).

The converter warns you in both cases. For a nonexistent time it follows the rule most languages use (JavaScript, Python zoneinfo, Java java.time): it pushes the time forward by the size of the jump (02:30 becomes 03:30). For a repeated time, you choose the first or the second occurrence.

Rules also change over time. Brazil, for example, abolished daylight saving time in 2019, but old dates keep the rules of their time: in São Paulo, 00:30 on November 4, 2018 never happened. Converting old dates with "today's" offset is off by an hour.

The year 2038 problem

Systems that store timestamps in a signed 32-bit integer stop at 2147483647, which is January 19, 2038, 03:14:07 UTC. One second later the number wraps around to December 13, 1901. Linux, databases and modern languages already use 64 bits, but firmware, embedded systems and old INT columns are still at risk. Try 2147483647 and 2147483648 in the converter.

ISO 8601 or RFC 2822?

• ISO 8601 (2023-11-14T17:13:20.000-05:00) is the standard for APIs, JSON and databases: it sorts correctly as text and doesn't depend on language. The trailing Z means UTC ("Zulu"). RFC 3339 is a stricter profile of it used on the internet.
• RFC 2822 (Tue, 14 Nov 2023 17:13:20 -0500) is the format of email headers and RSS feeds. Day and month names are always in English.

Dates written as 12/31/2024 or 31/12/2024 are rejected on purpose: they depend on the country and fail silently. Prefer 2024-12-31.

Getting and converting timestamps in each language

```text
JavaScript Math.floor(Date.now() / 1000) new Date(1700000000 * 1000).toISOString()
Python int(time.time()) datetime.fromtimestamp(1700000000, tz=timezone.utc)
Java Instant.now().getEpochSecond() Instant.ofEpochSecond(1700000000)
Go time.Now().Unix() time.Unix(1700000000, 0).UTC()
PHP time() date(DATE_ATOM, 1700000000)
PostgreSQL SELECT floor(extract(epoch FROM now())); SELECT to_timestamp(1700000000);
MySQL SELECT UNIX_TIMESTAMP(); SELECT FROM_UNIXTIME(1700000000);
Shell (GNU) date +%s date -u -d @1700000000
Shell (mac) date +%s date -u -r 1700000000
```

Limitations

• The range is that of JavaScript's Date: about 270,000 years before and after 1970. Micro- and nanoseconds are kept in the text output (ISO with 6 or 9 decimals), but calendar math works in milliseconds.
• Time zones and daylight saving history come from the IANA database built into your browser. Outdated browsers may miss a country's recent changes.
• A date-only ISO string (2024-03-10) is read as midnight in the chosen zone. Note that JavaScript's Date reads that same string as midnight UTC.

FAQ

Does a Unix timestamp have a time zone? No. It is always counted in UTC. The zone only matters for displaying a date or for interpreting a typed date and time.

Why does the same timestamp show different times on different computers? Each one displays it in its local zone. The instant is the same.

What about leap seconds? They are ignored: Unix time pretends they never happened, as virtually every system does.

Is my data sent anywhere? No. The conversion runs entirely in your browser, with no login and nothing stored.