Convert Unix timestamps (seconds or milliseconds since 1970-01-01 00:00:00 UTC) to human-readable dates and vice versa. Supports multiple time zones, ISO 8601, RFC 2822, and custom formats.
A Unix epoch timestamp (also known as Unix time, POSIX time, or Epoch time) is a system for describing a point in time as the number of seconds (or milliseconds) that have elapsed since January 1, 1970, 00:00:00 UTC (the Unix epoch). This simple, numeric representation of time is widely used in computing — from file systems and databases to APIs, logging, and cryptography — because it is timezone‑agnostic, easy to compare, and storage‑efficient.
Unix Timestamp = (target time in UTC) − (January 1, 1970 00:00:00 UTC)
Measured in seconds (10‑digit) or milliseconds (13‑digit). Negative values represent dates before the epoch.
The conversion from epoch to date relies on the JavaScript Date object, which internally stores time as milliseconds since the Unix epoch. The Date constructor accepts a numeric argument (milliseconds), and we can manipulate it using toUTCString(), toISOString(), and timezone‑aware formatters like Intl.DateTimeFormat.
For date‑to‑epoch, we parse a date string and time with a specified timezone, then obtain the UTC timestamp using Date.UTC() or by constructing a Date object with the correct timezone offset. This ensures that the resulting epoch value correctly represents the selected date and time in the chosen timezone.
Our tool handles both seconds (10 digits) and milliseconds (13 digits) automatically. The "Unit" selector lets you control how the input is interpreted, preventing off‑by‑1000 errors that are common when working with timestamps.
All values verified against authoritative time services (time.gov, NTP pools).
| Event | Date (UTC) | Epoch (seconds) | Epoch (milliseconds) |
|---|---|---|---|
| Unix Epoch Start | 1970-01-01 00:00:00 | 0 | 0 |
| Y2K (2000-01-01) | 2000-01-01 00:00:00 | 946684800 | 946684800000 |
| 2020-01-01 | 2020-01-01 00:00:00 | 1577836800 | 1577836800000 |
| 2038-01-19 03:14:07 | 2038-01-19 03:14:07 | 2147483647 | 2147483647000 |
| 2040-01-01 | 2040-01-01 00:00:00 | 2208988800 | 2208988800000 |
Imagine you're a backend engineer investigating a production issue. Your logs show a user session expired at timestamp 1735689600. Using this tool, you instantly see that this corresponds to 2025-01-01 00:00:00 UTC. You also check the local timezone (e.g., America/New_York) and see it was 2024-12-31 19:00:00 EST — which helps you correlate with user reports from that evening. With the ISO 8601 output, you can directly paste the value into your database query or monitoring dashboard.
On January 19, 2038, at 03:14:07 UTC, the Unix timestamp will reach 2,147,483,647 — the maximum value for a signed 32‑bit integer. Systems that store timestamps in 32‑bit signed integers will overflow, wrapping to negative values (which represent dates in 1901). This is known as the Year 2038 problem (or Y2K38). Many modern systems use 64‑bit integers, which can represent dates far into the future (up to the year 292 billion). Our converter supports 64‑bit values within JavaScript's safe integer range (Number.MAX_SAFE_INTEGER ≈ 9e15), covering dates well beyond 2038.
When you enter a timestamp near 2,147,483,647, the tool will correctly display the corresponding date. You can experiment with values beyond this limit to see how 64‑bit timestamps behave — a valuable educational exercise for students and developers learning about data types and time representation.
1700000000), while a milliseconds timestamp is 13‑digit (e.g., 1700000000000). Many programming languages (JavaScript, Java, Python) use milliseconds, while others (PHP, MySQL) use seconds. Always check the expected unit before converting.
-1 is 1969-12-31 23:59:59 UTC. The tool handles negative numbers correctly.
Number type is double‑precision floating point, with a safe integer range of ±9,007,199,254,740,991 (±9e15). This covers dates up to about 285,000 AD. For practical purposes, this is more than sufficient.
Intl.DateTimeFormat API with the IANA timezone database (e.g., America/New_York). This ensures accurate and up‑to‑date timezone offsets, including daylight saving transitions.
moment.js or date-fns with extended precision.