Convert Unix timestamps to human-readable dates and dates to epoch time. Supports seconds, milliseconds, and batch conversion.
| Epoch | Date (UTC) | Event |
|---|---|---|
| 0 | Jan 1, 1970 00:00:00 | Unix Epoch |
| 1000000000 | Sep 9, 2001 01:46:40 | Billennium |
| 1234567890 | Feb 13, 2009 23:31:30 | Sequential timestamp |
| 1500000000 | Jul 14, 2017 02:40:00 | 1.5 billion |
| 1700000000 | Nov 14, 2023 22:13:20 | 1.7 billion |
| 2000000000 | May 18, 2033 03:33:20 | 2 billion |
| 2147483647 | Jan 19, 2038 03:14:07 | Y2K38 (32-bit overflow) |
Unix epoch time (also called POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 00:00:00 UTC, not counting leap seconds. It is widely used in computing to represent dates and times as a single integer, making it easy to store, compare, and calculate time differences.
The date was chosen by the designers of Unix at Bell Labs as a convenient, round date close to when the system was being developed. The original Unix time was stored as a 32-bit integer counting 1/60th of a second intervals, and 1970 was chosen as a practical starting point that wouldn't overflow too quickly.
Unix epoch is traditionally measured in seconds (a 10-digit number like 1700000000). Many programming languages, including JavaScript and Java, use milliseconds instead (a 13-digit number like 1700000000000). This tool auto-detects the format based on the number of digits and converts accordingly.
Systems using 32-bit signed integers to store Unix timestamps will overflow on January 19, 2038 at 03:14:07 UTC, when the value exceeds 2,147,483,647. The counter will wrap to a negative number, potentially causing system crashes or incorrect dates. Most modern systems use 64-bit integers, which can represent dates billions of years into the future.
No. Unix epoch time explicitly does not count leap seconds. Each day is treated as exactly 86,400 seconds. When a leap second occurs, the Unix clock may repeat a second or adjust gradually depending on the system implementation (e.g., Google's "leap smear"). This means Unix time can differ from UTC by the accumulated number of leap seconds.