Unix Timestamp Converter: Epoch Time to Date and Date to Unix Time
Enter a Unix timestamp in the converter above to see it as an ISO 8601 date in UTC and in your local time zone, together with the same instant in seconds and in milliseconds. Or pick a date and time to get its Unix timestamp. The converter recognises 13-digit millisecond values automatically, which avoids the most common epoch mistake: reading milliseconds as seconds.
What epoch time is
Unix time, or epoch time, counts the seconds since 00:00:00 UTC on 1 January 1970, the Unix epoch, not counting leap seconds. It is a single number with no time zone, which is why logs, databases, APIs and tokens use it: 1790000000 is the same instant everywhere in the world.
0 1970-01-01T00:00:00Z the epoch
1000000000 2001-09-09T01:46:40Z
1790000000 2026-09-21T14:13:20Z
2147483647 2038-01-19T03:14:07Z largest signed 32-bit valueJWT claims exp, iat and nbf are Unix timestamps in seconds. Log files and monitoring tools often use seconds or milliseconds. HTTP APIs return them in rate-limit headers such as X-RateLimit-Reset. File systems record modification times as epoch values. Paste any of them into the converter to see the real date and time.
Seconds or milliseconds?
Unix timestamps are traditionally in seconds, but JavaScript, Java and many APIs use milliseconds. Count the digits: for current dates, 10 digits means seconds and 13 digits means milliseconds. The converter treats any value of 13 or more digits as milliseconds and shows both forms in the result.
1790000000 10 digits seconds 2026-09-21T14:13:20Z
1790000000000 13 digits milliseconds 2026-09-21T14:13:20Z
1790000000 read as ms 1970-01-21T17:13:20Z <- the classic bugA date in January 1970 almost always means a seconds value was treated as milliseconds. A date tens of thousands of years in the future means milliseconds were treated as seconds.
Time zones
The timestamp itself has no time zone; only its display does. The converter shows the ISO 8601 value in UTC (ending in Z) and the same instant in your browser's local time. Store and transmit UTC, and convert to local time only for display.
When converting a date to a timestamp, the date you pick is interpreted in your local time zone, because that is how the browser's date input works. If you mean a UTC time, subtract your UTC offset, or build the value in code with an explicit Z.
Around daylight-saving changes, some local times are ambiguous or do not exist. Timestamps are unaffected, which is another reason to store them rather than local date strings. For the same reason, subtracting two timestamps gives the exact elapsed seconds, but not always the number of calendar days or hours on the clock; for questions like "how many days until" or "how long did this shift last", a date difference calculator or a time duration calculator works in calendar terms.
Getting and converting timestamps in code
Math.floor(Date.now() / 1000) // JavaScript: now, in seconds
new Date(1790000000 * 1000).toISOString() // seconds -> ISO date
import time, datetime # Python
int(time.time())
datetime.datetime.fromtimestamp(1790000000, datetime.timezone.utc)
date +%s # shell: now
date -u -d @1790000000 # GNU/Linux: timestamp -> date
date -u -r 1790000000 # macOSIn SQL, PostgreSQL uses to_timestamp(1790000000) and extract(epoch from now()), and MySQL uses FROM_UNIXTIME() and UNIX_TIMESTAMP().
ISO 8601, RFC 3339 and RFC 2822
When a timestamp has to be readable, it is written as a date string, and three formats cover almost everything you will meet:
2026-09-21T14:13:20Z ISO 8601 / RFC 3339: APIs, JSON, logs
2026-09-21T17:13:20+03:00 the same instant with a UTC offset
Mon, 21 Sep 2026 14:13:20 +0000 RFC 2822 (now RFC 5322): email Date header
Mon, 21 Sep 2026 14:13:20 GMT HTTP date (RFC 9110): Last-Modified, ExpiresRFC 3339 is a strict profile of ISO 8601 for internet protocols: it requires a full date, a full time and an offset, either Z or +hh:mm. Use it for anything you store or send; every language can parse it. The RFC 2822 style survives in email and, with GMT, in HTTP headers; JavaScript's toUTCString() produces the HTTP form, and Python's email.utils.format_datetime the email form.
Negative timestamps and JavaScript Date pitfalls
Dates before 1970 are negative timestamps. -1 is 1969-12-31T23:59:59Z, and the Apollo 11 landing, 20 July 1969 at 20:17:40 UTC, is -14182940. The converter accepts negative values. When converting negative milliseconds to seconds, round down with Math.floor: Math.floor(-1500 / 1000) gives -2, the correct second, while Math.trunc gives -1.
JavaScript's Date has more traps that fail silently:
new Date('2026-09-21') // date only: parsed as UTC midnight
new Date('2026-09-21T12:00') // date and time, no offset: parsed as LOCAL time
new Date(2026, 0, 31) // months count from 0: this is 31 January
new Date(2026, 1, 31) // 31 February rolls over to 3 March, no error
new Date(8.64e15 + 1).getTime() // NaN: beyond Date's range of ±100 million daysThe first two lines differ by your UTC offset, which is why a date-only string can show up as the previous day west of Greenwich. Strings in other formats, such as 2026-09-21 14:13:20 with a space, are parsed by rules each engine defines for itself, so always include T and an offset or Z.
Timestamps in databases and the year 2038
Databases store dates in native types rather than raw numbers, and the types behave differently. PostgreSQL's timestamptz stores an absolute instant in UTC and displays it in the session's time zone, while timestamp without time zone stores wall-clock time with no zone at all. MySQL converts TIMESTAMP from the session time zone to UTC and back, while DATETIME is stored exactly as given. For instants, prefer timestamptz in PostgreSQL, and in MySQL set the connection time zone explicitly.
Systems that store Unix time in a signed 32-bit integer overflow at 03:14:07 UTC on 19 January 2038, wrapping to December 1901. MySQL's TIMESTAMP type is one of them: its documented range ends at 2038-01-19 03:14:07 UTC, while DATETIME reaches the year 9999. Modern operating systems and languages use 64-bit time, but embedded devices, old file formats and database columns declared as 32-bit integers can still be affected. Use 64-bit integer columns or native timestamp types without that limit for anything that stores future dates.
Frequently asked questions
How do I convert a Unix timestamp to a date?
Paste the timestamp into the converter. It shows the date in UTC (ISO 8601) and in your local time, and detects whether the value is in seconds or milliseconds.
What is epoch time?
The number of seconds since 00:00:00 UTC on 1 January 1970, not counting leap seconds. It identifies an instant independently of time zones.
How do I know if a timestamp is in seconds or milliseconds?
For current dates, seconds have 10 digits and milliseconds have 13. A result in January 1970 means seconds were read as milliseconds.
How do I get the current Unix timestamp?
In JavaScript use Math.floor(Date.now() / 1000), in Python int(time.time()), and in a shell date +%s.
Does a Unix timestamp have a time zone?
No. It is the same number everywhere; only the conversion to a readable date depends on a time zone. The converter shows both UTC and your local time.
What is the year 2038 problem?
Signed 32-bit Unix time overflows on 19 January 2038 at 03:14:07 UTC. Systems using 64-bit time are not affected.