About the Unix Timestamp Converter
Epoch conversion is one of the most-used developer utilities on the internet, served by pages that have not changed since 2010. This one does the job properly: paste anything — seconds, millis, micros, nanos, ISO 8601, RFC 2822 — and it tells you what it detected, then converts every direction, timezone-aware both ways with real DST handling for the skipped and repeated hours.
The engine was validated in Node before shipping — 1,088 assertions against an independent parser, published epoch identities (the billennium, 1234567890, the 2038 boundary), and wall-clock round trips across DST transitions in six timezones.
One second past the boundary, a 32-bit signed timestamp wraps to −2,147,483,648 — which decodes as 13 December 1901. Your laptop is fine; 64-bit time is good for 292 billion years. The problem lives in embedded controllers, old file formats, and every database column someone declared as a 32-bit INT to hold seconds. The fix everywhere is the same: audit where timestamps are stored, not just where they are computed.
How to Use the Unix Timestamp Converter
Paste anything into the box. Ten digits reads as epoch seconds, thirteen as milliseconds, sixteen as microseconds, nineteen as nanoseconds; ISO 8601 and RFC 2822 strings are recognised outright, and the detection line always states what was assumed. Every format comes back at once — UTC, your local time, any timezone from the full IANA list, all four epoch precisions, and a relative “3 days ago.” The reverse direction is a date-time-zone picker that handles daylight-saving edges correctly.
Reference Points Worth Memorising
- 0 — 1970-01-01 00:00:00 UTC, the epoch itself.
- 1,000,000,000 — 2001-09-09, the “billennium.”
- 1,234,567,890 — 2009-02-13 23:31:30 UTC, celebrated at the time.
- 2,147,483,647 — 2038-01-19 03:14:07 UTC, the end of signed 32-bit time.
- ~86,400 per day, ~31.6 million per year — for sanity-checking arithmetic at a glance.
The Two Mistakes Every Codebase Makes Eventually
Unit confusion: passing milliseconds where seconds are expected produces dates around the year 56,000; the reverse lands you in January 1970. If a date looks absurd, divide or multiply by 1,000 before debugging anything else. Zoneless strings: “2024-01-15T10:30:00” is a different instant in every timezone, the spec says local, half of all APIs mean UTC, and the only safe habit is to write the Z or the offset. This converter refuses to guess silently on either — it labels the assumed unit and asks about the missing zone.
Related tools: the Cron Expression Builder for when things should run, the JSON Formatter for the payloads timestamps arrive in, and the Date Duration Calculator for human-calendar spans. Browse every Dev & Tech tool for more.
Frequently Asked Questions
What is a Unix timestamp?
The number of seconds since 1970-01-01 00:00:00 UTC — the Unix epoch — not counting leap seconds. It is the closest thing computing has to a universal clock: no timezone, no calendar, no locale, just a monotonically increasing integer, which is why databases, logs and APIs lean on it. Variants count milliseconds (JavaScript), microseconds (many databases) or nanoseconds (Go, protobuf); the digits give it away, and this tool reads all four.
How does the tool know if I pasted seconds or milliseconds?
By magnitude. Ten digits (up to ~2.1 billion) is seconds through the year 5138; thirteen digits is milliseconds over the same era; sixteen microseconds; nineteen nanoseconds. The detection line always states which unit was assumed, so an ambiguous paste never converts silently — and a decimal point (1700000000.5) always means seconds with a fraction.
What is the year 2038 problem?
At 03:14:07 UTC on 19 January 2038, the epoch reaches 2,147,483,647 — the largest value a signed 32-bit integer holds. One second later, a program storing time in 32 bits wraps to −2,147,483,648, which reads as 13 December 1901. Modern 64-bit systems are fine for 292 billion years, but 32-bit time_t survives in embedded devices, old file formats, and databases with INT columns holding timestamps — which is why the fix is a schema audit, not an OS upgrade. The countdown panel on this page is live.
Why does an ISO date without a timezone need a decision?
Because "2024-01-15T10:30:00" names a wall-clock moment, not an instant — it happens at different epochs in Tokyo and Toronto. The ISO 8601 standard says a zoneless time is local time, but APIs routinely mean UTC. When you paste one, this tool shows both readings and lets you pick the zone it was meant in, rather than guessing silently the way most converters do.
How are the skipped and repeated DST hours handled?
When you build a date in a zone that is mid-transition: a time that does not exist (2:30 AM on the US spring-forward night) resolves to the adjacent real instant, and a time that happens twice (1:30 AM on the fall-back night) resolves to the first occurrence — the same conventions operating systems use. The engine's DST behaviour is validated round-trip against the browser's own timezone database in six zones.
