Unix Timestamp Converter
Convert epoch timestamps to human dates across timezones, with a live now ticker.
- ISO 8601 (UTC)
- 2025-06-15T15:06:40.000Z
- RFC 2822 / HTTP date
- Sun, 15 Jun 2025 15:06:40 GMT
- Relative
- 12 months ago
- Selected timezone — UTC
- 15 Jun 2025, 15:06:40
- UTC
- 15 Jun 2025, 15:06:40
- America/New_York
- 15 Jun 2025, 11:06:40
- America/Los_Angeles
- 15 Jun 2025, 08:06:40
- Europe/London
- 15 Jun 2025, 16:06:40
- Asia/Tokyo
- 16 Jun 2025, 00:06:40
- Epoch seconds / milliseconds
- 1750000000 / 1750000000000
How it works
A Unix timestamp is the number of seconds elapsed since 00:00:00 UTC on January 1, 1970 — the epoch. This converter goes both directions: paste an epoch value and read it as a human date, or pick a date and time and get the epoch back. The two fields stay in sync, so editing either side updates the other immediately, and the conversions grid below shows the same instant rendered every way you commonly need it.
Whether your number is seconds or milliseconds is auto-detected by magnitude: today's time in seconds is ten digits, in milliseconds thirteen. The detected unit is shown next to the field so the guess is never silent — if you have ever seen a date render as January 1970, you have met the bug this label prevents. JavaScript's Date.now(), Java's System.currentTimeMillis() and many logging pipelines emit milliseconds, while Unix tools, Python's time.time() and most REST APIs speak seconds.
The conversions grid renders ISO 8601, the RFC 2822 / HTTP-date form, a relative phrase ("3 days ago") computed with Intl.RelativeTimeFormat, and the wall-clock time in five reference timezones — UTC, US Eastern and Pacific, London and Tokyo — plus whichever timezone you select from the picker. All formatting uses the browser's own Intl machinery, so DST rules and timezone offsets come from your platform's up-to-date IANA database rather than a hardcoded table.
The live ticker at the top shows the current epoch second, updating every second, with a copy button — the fastest way to grab "now" for a test fixture or an expiry field. A note on storage practice, since this tool exists because of its violations: persist UTC (the timestamp itself), attach the user's IANA timezone name separately when wall-clock context matters, and convert at render time only. Timestamps written in local time are the root cause of a remarkable share of off-by-one-hour bugs every March and November, when daylight-saving transitions quietly shift the meaning of every stored local time.
Frequently asked questions
Is my timestamp in seconds or milliseconds?
Magnitude gives it away, and this tool auto-detects on that basis: current Unix time in seconds is a 10-digit number (around 1.7–1.8 billion), while milliseconds is 13 digits. If a date renders as 1970 when you expected this year, your value was seconds being read as milliseconds; if it renders tens of thousands of years in the future, the reverse. JavaScript's Date.now() returns milliseconds; most Unix tools and APIs use seconds.
What is the 2038 problem?
Systems storing Unix time in a signed 32-bit integer overflow at 03:14:07 UTC on January 19, 2038, when the count of seconds since 1970 exceeds 2,147,483,647 — wrapping to a negative number that reads as December 1901. Modern 64-bit systems and languages are unaffected, but embedded devices, old database schemas with INT columns, and legacy file formats still carry the risk. If you design schemas today, use 64-bit integers or native timestamp types.
Should I store timestamps in UTC or local time?
Store UTC, always — convert to local time only at the display edge. Local-time storage breaks twice a year at daylight-saving transitions (one wall-clock hour repeats, another never exists), breaks again when servers or users change timezones, and makes cross-region data impossible to compare. A Unix timestamp is inherently UTC, which is one of its virtues; pair it with the user's IANA timezone name when you need to reconstruct their wall-clock view.
Do Unix timestamps count leap seconds?
No. Unix time pretends every day is exactly 86,400 seconds, so when a leap second is inserted into UTC the Unix clock effectively repeats or smears a second rather than counting 86,401. For almost all engineering purposes this is a feature — arithmetic stays trivial — and large providers handle the discrepancy by smearing the leap second across many hours. Only specialized domains like astronomy and satellite navigation need true leap-second-aware timescales.
What is the difference between ISO 8601 and RFC 2822 formats?
ISO 8601 (2026-06-11T14:30:00Z) is the modern interchange standard: lexicographically sortable, unambiguous, and the format JSON APIs should use. RFC 2822 (Thu, 11 Jun 2026 14:30:00 GMT) is the older email-header style still seen in HTTP Date headers and some legacy APIs. Both encode the same instant; prefer ISO 8601 for anything new and parse RFC 2822 only when a protocol forces it.
Built by FORG — AI cost observability for agentic coding. Free tools, no signup, nothing leaves your browser.
Learn about FORG