Unix Timestamp ConverterConvert epochs to readable dates and back in real time
Choose seconds or milliseconds explicitly. UTC output uses ISO 8601 with milliseconds; local output uses your browser's timezone.
Pick a local date/time, set the seconds field, and copy either seconds or milliseconds.
This is a local time, not UTC. At daylight-saving transitions, JavaScript chooses the earlier repeated time or moves a skipped time forward. Date/time behavior.
Seconds or milliseconds: which one do you have?
A Unix timestamp counts time from 1970-01-01 00:00:00 UTC. POSIX defines "seconds since the Epoch" as a value that approximates elapsed seconds and treats every day as exactly 86,400 seconds, so leap seconds are not counted. JavaScript's Date counts milliseconds; most Unix tools and many APIs count seconds. For dates near the present you can tell them apart by length:
| Digits | Unit | Example | What to do in this tool |
|---|---|---|---|
| 10 | seconds | 1710352200 | Unit: Seconds |
| 13 | milliseconds | 1710352200000 | Unit: Milliseconds |
| 16 | microseconds | 1710352200000000 | Divide by 1,000, then use Milliseconds |
Check it yourself. Enter 1710352200 with the unit set to Seconds: UTC shows 2024-03-13T17:50:00.000Z. Leave the digits and switch the unit to Milliseconds and you get 1970-01-20T19:05:52.200Z, a date in January 1970. Enter the 13-digit 1710352200000 as Seconds and the result is +056168-11-26T01:20:00.000Z, a year in the 56,000s. Either symptom means the unit is wrong.
One instant, three wall-clock times
An epoch value has no time zone; only its display does. The UTC line in the tool is ISO 8601 with a trailing Z (the RFC 3339 profile), and the Local line follows your browser's zone. The Date-to-Epoch side reads your input as local time, so the same wall-clock entry gives different epochs in different zones.
| Zone | Wall-clock time for 1710352200 | Note |
|---|---|---|
| UTC | 2024-03-13 17:50:00 | UTC |
| America/Toronto | 2024-03-13 13:50:00 | EDT, UTC-4 (DST began 2024-03-10) |
| Asia/Tokyo | 2024-03-14 02:50:00 | JST, UTC+9 (next calendar day) |
The year 2038 limit
A signed 32-bit seconds counter tops out at 231 − 1. One second later it does not fit, and a naive implementation wraps to a negative number. Systems that store the count in 64 bits, and JavaScript, are not affected; the ECMAScript Date range is ±100,000,000 days around 1970.
| Seconds | UTC | Meaning |
|---|---|---|
2147483647 | 2038-01-19T03:14:07.000Z | largest signed 32-bit value (2^31 - 1) |
2147483648 | 2038-01-19T03:14:08.000Z | one second later; needs 64 bits |
-2147483648 | 1901-12-13T20:45:52.000Z | what a signed 32-bit counter wraps to |
Current time and conversion in code
Math.floor(Date.now() / 1000) // seconds, 10 digits
new Date(1710352200 * 1000).toISOString() // '2024-03-13T17:50:00.000Z'from datetime import datetime, timezone
datetime.fromtimestamp(1710352200, tz=timezone.utc).isoformat()
# '2024-03-13T17:50:00+00:00'date -u -d @1710352200 +%Y-%m-%dT%H:%M:%SZ # GNU/Linux
date -u -r 1710352200 +%Y-%m-%dT%H:%M:%SZ # macOS/BSD
# both print 2024-03-13T17:50:00ZQuestions
- Can I enter a negative timestamp?
- Yes.
-1in seconds gives1969-12-31T23:59:59.000Zbecause JavaScript handles dates before 1970. POSIX leaves the mapping undefined for negative values, so other systems may differ. - Why is there no microsecond option?
- JavaScript dates have millisecond resolution. Divide a microsecond value by 1,000 and use the Milliseconds unit; the extra digits are lost.