Timestamp Converter — Unix epoch and ISO 8601

Paste any Unix timestamp (seconds or milliseconds) or any ISO 8601 string and see it expanded into all common formats. Pick your favourite IANA timezone for the human-readable output.

What is a Unix timestamp?

A Unix timestamp is the number of seconds (or milliseconds, in JavaScript) elapsed since 1970-01-01T00:00:00Z, the 'epoch'. It's a single integer that has no notion of timezone and rolls over the same way for every computer on Earth — properties that make it the de-facto exchange format for dates between systems.

Humans don't read epoch values; they read calendar dates and clock times in their own timezone. ISO 8601 (e.g. 2026-05-07T13:00:00Z) bridges the two: it's a textual format that's still unambiguous, sortable as a string, and round-trips through every modern date library. This converter keeps all three views in sync so you can paste any of them and read off the others.

How to use this tool

Paste a Unix timestamp on the left (seconds by default, switch to ms if your value has 13 digits) — or an ISO 8601 string on the right.
Pick a timezone from the dropdown to format the local time. Your browser's timezone is preselected.
Click Copy on any row to put that representation in your clipboard. The 'Current Unix time' display updates every second and is itself copyable.

Frequently asked questions

Are timestamps in seconds or milliseconds?

It depends on the platform. Unix utilities, most APIs and the C 'time_t' use seconds. JavaScript's Date.now() and most JS libraries use milliseconds. A 10-digit value is seconds; 13 digits is milliseconds.

What's the relationship between Unix time and UTC?

Unix time counts seconds since the same instant — the 1970-01-01T00:00:00Z epoch — regardless of where the clock physically is. So Unix time is essentially UTC, minus leap seconds. Two computers in different timezones with synchronised clocks share the same Unix time.

Why does my date show a different day in 'local time'?

Because the same instant in UTC can fall on a different day in your timezone. 2026-05-07T01:30:00Z is still 2026-05-06 in Los Angeles (UTC-7). Always store and exchange in UTC; only convert to local time at the edge, when displaying.

What about leap seconds?

Unix time deliberately ignores leap seconds: the day always counts as 86,400 seconds. That keeps arithmetic simple and is what every database, programming language and OS does in practice. If your domain requires astronomical accuracy, use TAI or UT1 instead.

Will Unix timestamps overflow in 2038?

Only on systems that store time in a signed 32-bit integer of seconds. Every modern OS, language and database uses at least 64-bit, which extends the range to 292 billion years. The 'Y2038 problem' is real on legacy embedded systems but a non-issue for new code.

Common use cases

Real situations where flipping between epoch and human time pays off.

Inspect an API response

An API returned createdAt: 1746619200 — paste it here and you instantly know it's 2025-05-07 12:00 UTC, not the 1746-something nonsense your eyes initially saw.

Schedule a cron or queue job

Generate a Unix timestamp for 'tomorrow at 9 AM Paris time' to feed into an at-style scheduler or a delayed queue job. The converter shows the offset for the chosen timezone so you can sanity check the result.

Debug timezone bugs

Convert the same instant in two timezones (UTC vs your local) to see whether a bug is in the storage layer or in the display layer. Most timezone bugs are display-only and disappear when you stick to UTC internally.

Fill in a database test fixture

Need a date 30 days in the future for a test? Type the human form, copy the Unix timestamp, paste into the fixture. Round-trip safe, no off-by-one because the parser is the same one your code uses.

Tips and shortcuts

Small habits that prevent timezone disasters.

Store and transmit in UTC

Save dates as Unix timestamps or as ISO 8601 with the Z suffix. Convert to local time only at the user-facing edge of your stack. Doing the opposite causes summer-time bugs every March and October.

Use IANA timezone names, not offsets

'Europe/Paris' encodes the historical and DST rules; '+0200' is just the offset right now. Storing the offset breaks future-dated events as soon as DST flips.

Beware Date.parse() ambiguity

Across browsers, 'YYYY-MM-DD' alone is parsed as UTC midnight, while 'YYYY-MM-DDTHH:MM:SS' (without Z) is parsed as local time. Always include the Z or an explicit offset in strings you store.

Test around DST boundaries

Most timezone bugs hide near the spring-forward and fall-back days. If you have time-related code, test it explicitly with timestamps inside the DST transition hour for the last user's timezone.