Unix Timestamp Converter
Convert between Unix timestamps and dates.
About this tool
Convert Unix timestamps in seconds, milliseconds or microseconds to ISO 8601, local time and relative time, or turn any date string back into a timestamp.
How to use it
- Paste a Unix timestamp in seconds, milliseconds or microseconds, or any date string.
- The unit is detected from the number of digits.
- Read the date in ISO 8601, your local time, RFC 2822 and relative form, and copy what you need.
Questions
- What is a Unix timestamp?
- The number of seconds since 1 January 1970 00:00:00 UTC, known as the Unix epoch. It is the same everywhere in the world, which makes it ideal for storing moments in time.
- Seconds or milliseconds?
- A current timestamp in seconds has 10 digits, in milliseconds 13. Unix tools and most APIs use seconds; JavaScript’s Date.now() returns milliseconds.
- What is the year 2038 problem?
- Systems that store timestamps as signed 32-bit integers overflow on 19 January 2038. Modern systems use 64-bit values and are not affected.
- How are dates before 1970 written as Unix timestamps?
- As negative numbers. -86400 is 31 December 1969 at 00:00 UTC, one day before the epoch, and this converter accepts the minus sign. Some older systems and libraries reject negative timestamps, so check before storing historical dates such as birth dates this way.
- Do Unix timestamps include leap seconds?
- No. Unix time treats every day as exactly 86,400 seconds and ignores leap seconds. When one occurs, the system clock repeats a second or, at Google and AWS, spreads it across several hours, which is called smearing. For almost all applications you can safely ignore this.
- How do I convert a Unix timestamp in Excel or Google Sheets?
- Use =A1/86400 + DATE(1970,1,1) and format the cell as a date and time. The result is in UTC, so add your offset divided by 24 for local time. For a timestamp in milliseconds, divide by 86400000 instead of 86400.
How to get the current Unix timestamp in any language
Most languages return the current epoch time in one call. In JavaScript, Date.now() returns milliseconds, so use Math.floor(Date.now() / 1000) for seconds. Python’s time.time() returns seconds as a float, and in a shell date +%s prints seconds. Go has time.Now().Unix(), Java has Instant.now().getEpochSecond(), and PostgreSQL has extract(epoch from now()). The top of this page shows the live value in seconds and milliseconds.
Going the other way is just as short: new Date(ts * 1000).toISOString() in JavaScript, datetime.fromtimestamp(ts, tz=timezone.utc) in Python, date -d @1762540800 on Linux or date -r 1762540800 on macOS. The most frequent bug is mixing units. Pass seconds to a function that expects milliseconds and you land in January 1970; pass milliseconds where seconds are expected and you get a date tens of thousands of years ahead.
ISO 8601 vs Unix time: which format to store
Unix time is a single number: easy to compare, sort and calculate with, and free of time zone confusion. ISO 8601 strings like 2026-11-07T20:00:00Z are readable by people and can carry an offset when you need one, as in 2026-11-07T21:00:00+01:00. Both describe an exact instant. RFC 3339 is the stricter internet profile of ISO 8601 that most APIs actually follow.
A good rule is to store instants as a native timestamp type or as Unix time, and to send ISO 8601 with a Z or an offset in APIs and logs. Avoid strings without any zone, like 2026-11-07 20:00, because each reader may assume a different one. This epoch converter reads such strings as UTC and says so in a note. It also understands log formats such as 06/Nov/2026:09:15:02 +0000.
Why is my converted timestamp off by a few hours?
A Unix timestamp has no time zone; it counts seconds since the epoch in UTC. If a converted date looks a few hours off, the timestamp is usually fine and the display is the issue. Compare the ISO 8601 (UTC) row with the Local row here: they show the same instant, once in UTC and once in your browser’s time zone. Code that formats dates without a zone uses the machine’s local one.
The other common cause is a timestamp created from local wall time. In Python, datetime.utcnow().timestamp() is the classic example: the naive UTC value is treated as local time, so the result is off by your UTC offset. Use datetime.now(timezone.utc) instead. A difference of exactly 3600 or 7200 seconds points to this kind of bug. The Time Zone Converter shows what the wall clock read in each zone.
Notable Unix timestamps
Milestones of Unix time, in seconds since 1 January 1970 UTC.
| Timestamp | Date (UTC) | Why it matters |
|---|---|---|
0 | 1970-01-01T00:00:00Z | The Unix epoch: where counting starts |
1000000000 | 2001-09-09T01:46:40Z | One billion seconds |
1234567890 | 2009-02-13T23:31:30Z | The digits 1 to 0 in order, celebrated by programmers |
2000000000 | 2033-05-18T03:33:20Z | Two billion seconds |
2147483647 | 2038-01-19T03:14:07Z | Largest signed 32-bit value: the year 2038 problem |
4294967295 | 2106-02-07T06:28:15Z | Largest unsigned 32-bit value |
Something not working, or a result looks wrong? Report a problem with this tool