Unix Timestamp Converter — Epoch to Date and Date to Epoch
Convert epoch seconds, milliseconds, microseconds or nanoseconds to dates in any time zone, and back. Live clock, batch mode, code snippets.
Timestamp to date
Date to timestamp
Start and end of day, week, month, year
Batch convert
| 1700000000 | s | |
| 1760572800000 | ms | |
| -1 | s | |
| 2038-01-19 03:14:07 | date | |
| 0 | s |
Get the current timestamp in code
Math.floor(Date.now() / 1000) // seconds Date.now() // milliseconds
Runs entirely in your browser. Nothing you enter is sent to us or stored. Browse all free tools.
Found a problem, or something that could be better? We read every message and we fix things quickly.
This Unix timestamp converter turns an epoch value into a readable date and a date back into an epoch value, in UTC, your own time zone or any of the roughly 400 IANA zones your browser knows. Paste 1760572800, 1760572800000 or a 19-digit nanosecond value from a log line: the unit is detected from the number of digits, and you can override it when a value is ambiguous.
Large and unusual values are handled exactly. Digits are parsed as BigInt, so a nanosecond timestamp keeps its last digits instead of being rounded; negative timestamps before 1970 floor to the correct millisecond; and anything outside the JavaScript date range (about 271,821 BC to 275,760 AD) is reported as out of range rather than printed as "Invalid Date". Time zone offsets, including daylight saving changes, come from your browser's own time zone data. Nothing you enter leaves the page.
How to use
- Paste a timestamp into the first field. The table shows it in UTC, your zone, the selected zone, ISO 8601, RFC 2822 and relative time.
- If the unit is wrong (a 12-digit value can be seconds after 5138 AD or milliseconds in 1973), choose it in the Unit menu.
- To go the other way, type a date as YYYY-MM-DD HH:mm:ss and pick the zone it was written in; ISO strings with Z or an offset are read as-is.
- Use the start/end table for range queries such as "everything from this month", and the batch box for a column of values from a CSV or log.
- Copy any value with its button, or copy the snippet for your language to get the current timestamp in code.
Frequently asked questions
What is a Unix timestamp?
A Unix timestamp (epoch time) is the number of seconds elapsed since 00:00:00 UTC on 1 January 1970, not counting leap seconds. It has no time zone: the same instant has the same timestamp everywhere, which is why databases and APIs use it. Many systems store milliseconds instead (JavaScript's Date.now(), Java's currentTimeMillis), and some store microseconds or nanoseconds.
How do I tell if a timestamp is in seconds or milliseconds?
Count the digits. A current timestamp in seconds has 10 digits, in milliseconds 13, in microseconds 16 and in nanoseconds 19. This tool uses those boundaries automatically. The only ambiguous range is 11 to 12 digits, which is either seconds far in the future or milliseconds in the early 1970s; pick the unit by hand there.
What is the year 2038 problem?
Systems that store Unix time as a signed 32-bit integer can count only up to 2,147,483,647, which is 03:14:07 UTC on 19 January 2038. One second later the value wraps to a negative number and reads as December 1901. Modern operating systems, languages and databases use 64-bit time, but old embedded devices, file formats and database columns declared as 32-bit INT still have the problem.
Do Unix timestamps include leap seconds?
No. Unix time treats every day as exactly 86,400 seconds, so a leap second is not counted and the timestamp repeats or stalls for one second when one occurs. That makes date arithmetic simple at the cost of being off from atomic time (TAI) by the accumulated leap seconds, currently 37. For almost all application work this does not matter.
Can a Unix timestamp be negative?
Yes. Negative values count backwards from 1970: -1 is 23:59:59 UTC on 31 December 1969, and -86400 is the start of that day. Most languages handle negative timestamps correctly, but some older APIs and spreadsheet functions reject them, so check before storing dates of birth or historical dates as epoch values.
Why does my converted time look a few hours off?
Almost always a time zone mix-up: the timestamp is correct, but it was displayed in UTC when you expected local time, or a local date string was parsed as UTC. A timestamp itself never carries a zone. Check the zone selector here, and in code make sure a date string without an offset is interpreted in the zone you intend.
Seconds, milliseconds, microseconds, nanoseconds: who uses which
• Seconds (10 digits): Unix and POSIX time(), PHP time(), Python int(time.time()), PostgreSQL EXTRACT(EPOCH), JWT exp/iat/nbf claims, most HTTP APIs.
• Milliseconds (13 digits): JavaScript Date.now(), Java System.currentTimeMillis(), Elasticsearch and many JSON APIs, Kafka record timestamps.
• Microseconds (16 digits): PostgreSQL's internal timestamp storage, Python datetime precision, Google BigQuery TIMESTAMP_MICROS.
• Nanoseconds (19 digits): Go time.UnixNano(), Python time.time_ns(), InfluxDB and Prometheus remote-write, Linux clock_gettime. A JavaScript number cannot hold these exactly, which is why this tool parses them as BigInt.
When two systems disagree by a factor of 1,000, one is in seconds and the other in milliseconds. That single mistake accounts for most "date shows 1970" and "date shows year 50,000" bugs.
Time zones and daylight saving: what can go wrong
Converting a timestamp to a local time is always unambiguous: one instant maps to one wall-clock reading in each zone. Going the other way is not. When clocks spring forward, a local time such as 02:30 on the change day never happens; when they fall back, 01:30 happens twice.
This converter follows the same rules as the JavaScript Temporal API's default: a skipped time is read with the offset from before the change (so 02:30 becomes 03:30 daylight time), and a repeated time resolves to the first occurrence. If your code uses a different rule, the result can be an hour apart around those two dates each year.
The safest practice is to store and transmit instants as UTC timestamps or ISO 8601 strings with an explicit offset, and to convert to local time only for display, using an IANA zone name such as America/Toronto rather than a fixed offset like -05:00, which is wrong for half the year.
ISO 8601 vs RFC 2822 vs Unix time
ISO 8601 (2026-10-16T08:00:00Z or 2026-10-16T04:00:00-04:00) sorts correctly as text, is unambiguous, and is what JSON APIs, HTML datetime attributes and most databases expect. Use it whenever a human might read the value.
RFC 2822 (Fri, 16 Oct 2026 08:00:00 +0000) is the email and HTTP-header format. It is readable but does not sort as text, and it is defined only for years 1900 onward.
A Unix timestamp is the most compact and the fastest to compare, but it is unreadable without a converter and gives no hint of its unit. A reasonable rule: Unix time inside a system, ISO 8601 at its boundaries.
Related free tools
- Cron Expression Generator — Build a cron schedule from dropdowns or paste one, read it in plain English, and see the next 10 run times in your zone and UTC. Free, in your browser.
- JWT Decoder — Decode a JWT's header and payload, read the expiry in plain language, verify HS, RS, PS and ES signatures, or sign a new token. Nothing leaves your browser.
- UUID Generator — Generate UUID v4 or time-ordered v7, ULIDs and NanoIDs in bulk, or paste an ID to see its version and embedded timestamp.
- Number Base Converter — Convert integers of any size between binary, octal, decimal, hex, base 32, base 36 and any base 2–36, with a two's complement view.