Unix Timestamp Converter
Convert Unix timestamps (epoch time) to dates and back. Seconds, milliseconds, microseconds and nanoseconds are detected from the digit count, so you can paste a 10-digit or a 13-digit value without thinking about it. Results are shown in your own time zone, in UTC, and in ISO 8601, with one-click copy on every row. Built for reading logs and API responses.
This tool has been used … times.
1
The Current Unix Timestamp
The timestamp for right now, refreshed four times a second. Copy it straight into a test fixture or a query.
Unix seconds (10 digits)
–
Unix milliseconds (13 digits)
–
UTC
–
2
Unix Timestamp to Date
Paste a number and the unit is worked out from the digit count. You can also pin the unit yourself.
Load a common value
3
Date to Unix Timestamp
Pick a date and time to get Unix seconds, Unix milliseconds and ISO 8601. Choose which time zone the value you typed should be read as.
How to Use
- Paste the number you copied out of a log or an API response into the “Unix timestamp” field. The unit is detected from the digit count, so 10-digit and 13-digit values both work as they are. Even a fragment like
created_at: 1769490245,works: any run of 8 or more digits is pulled out automatically. - Switch between your own time zone, UTC and JST to read the date, and copy any row with the button beside it.
- To go the other way, fill in the “Date to Unix Timestamp” panel. Your input is saved automatically and restored the next time you open the page.
Unix Timestamp Reference
Telling the unit from the digit count
| Digits | Unit | Example | Where it comes from |
|---|---|---|---|
| 10 | Seconds | 1769490245 | PHP time(), shell date +%s, Python time.time() |
| 13 | Milliseconds | 1769490245123 | JavaScript Date.now(), Java System.currentTimeMillis() |
| 16 | Microseconds | 1769490245123456 | Distributed tracing spans and high-resolution access logs |
| 19 | Nanoseconds | 1769490245123456789 | Go time.Now().UnixNano(), Python time.time_ns() |
Reading a 13-digit value as seconds lands you more than fifty thousand years in the future, which is exactly why the digit count is such a reliable tell. Values pasted with thousands separators are fine too; commas, spaces and underscores are stripped automatically.
Seconds in common intervals
| Interval | Seconds | Typical use |
|---|---|---|
| 1 minute | 60 | The smallest unit for things like token lifetimes |
| 1 hour | 3,600 | Time zone offsets (UTC+09:00 is 32,400 seconds) |
| 1 day | 86,400 | Daily batch jobs, pulling the last 24 hours of logs |
| 1 week | 604,800 | Weekly rollups, week-on-week comparisons |
| 30 days | 2,592,000 | Cache retention, a rough month boundary |
| 365 days (common year) | 31,536,000 | Retention measured in years |
| 366 days (leap year) | 31,622,400 | A year that crosses 29 February |
Unix time counts every day as exactly 86,400 seconds, so leap seconds never move the number. Only the extra day in a leap year shows up, as the last two rows show.
Start of each year, 00:00:00 UTC
| Year | Unix seconds |
|---|---|
| 2020 | 1,577,836,800 |
| 2021 | 1,609,459,200 |
| 2022 | 1,640,995,200 |
| 2023 | 1,672,531,200 |
| 2024 | 1,704,067,200 |
| 2025 | 1,735,689,600 |
| 2026 | 1,767,225,600 |
| 2027 | 1,798,761,600 |
| 2028 | 1,830,297,600 |
| 2029 | 1,861,920,000 |
| 2030 | 1,893,456,000 |
Two consecutive rows give you the bounds for a whole year, which is what you want for a query like ts >= 1767225600 AND ts < 1798761600. For a year boundary in a different zone, subtract the offset: UTC+09:00 starts 32,400 seconds earlier.
Round numbers and the dates they land on
| Unix seconds | UTC | What it is |
|---|---|---|
| 0 | 1970-01-01 00:00:00 | The epoch. Anything earlier is negative |
| 1,000,000,000 | 2001-09-09 01:46:40 | The moment it reached 10 digits |
| 1,500,000,000 | 2017-07-14 02:40:00 | A round value you often see in test data |
| 2,000,000,000 | 2033-05-18 03:33:20 | The next round milestone |
| 2,147,483,647 | 2038-01-19 03:14:07 | The largest signed 32-bit integer, the year 2038 problem |
Unix Timestamp Basics
Unix timestampTime expressed as the number of seconds elapsed since 1970-01-01 00:00:00 UTC. Also called epoch time or POSIX time. Being a plain integer, it survives moving between languages and databases
The epoch1970-01-01 00:00:00 UTC. That instant is 0, and anything before it is negative
Seconds against milliseconds10 digits means seconds, 13 means milliseconds. JavaScript’s Date.now() and Java return milliseconds, while PHP’s time() and most Unix commands return seconds
Microseconds and nanoseconds16 digits means microseconds, 19 means nanoseconds. Common in distributed tracing and logging pipelines, such as Go’s time.UnixNano()
No time zone is carriedA Unix timestamp is a single value measured against UTC and holds no regional information. Whether you read it as London time or Tokyo time is entirely a display decision
ISO 8601A format such as 2026-07-27T15:04:05+09:00 that writes the date, the time and the offset from UTC together. A trailing Z means UTC
The year 2038 problemStoring seconds in a signed 32-bit integer overflows at 2147483647, which is 2038-01-19 03:14:07 UTC. Moving to 64-bit storage resolves it
Leap seconds are ignoredUnix time counts every day as 86,400 seconds, so leap seconds are never added. Timekeeping that has to be exact below the second needs a different mechanism
Frequently Asked Questions
- What is the difference between a 10-digit and a 13-digit timestamp?
- Only the unit. A 10-digit value counts seconds (1769490245) and a 13-digit value counts milliseconds (1769490245123); both describe the same kind of instant. Read a 13-digit value as seconds and you land more than fifty thousand years in the future, which makes the digit count a dependable signal. This tool detects the unit automatically and prints what it decided just under the input field.
- Does a Unix timestamp include a time zone?
- No. A Unix timestamp is a single number measured against UTC, and the same instant produces the same value anywhere in the world. There is no such thing as a “timestamp in local time”, so never add or subtract your offset before storing it. Doing that guarantees inconsistencies later; store the plain value and convert only when displaying.
- What is the year 2038 problem?
- On systems that hold Unix timestamps in a signed 32-bit integer, the maximum is 2147483647, which is 2038-01-19 03:14:07 UTC. Past that the value overflows and dates wrap around to 1901. Modern 64-bit environments are unaffected in practice, but old embedded devices and database columns still defined as 32-bit integers are not. The preset button loads the exact value so you can see it convert.
- Can it convert dates before 1970?
- Yes. Anything before the epoch is negative, so -86400 is 1969-12-31 00:00:00 UTC. This tool accepts a leading minus sign. Be aware that some systems never expected negative timestamps, so check what your storage layer does before relying on them.
- Can I paste text from a log without cleaning it up first?
- Yes. Given something like
created_at: 1769490245,the tool picks out the longest run of 8 or more digits and converts that. It reports which number it extracted just below the field, so you can confirm it chose the one you meant. Commas, spaces and underscores are stripped as well, so1,769,490,245is fine as it stands. - How do I turn milliseconds into seconds?
- Divide by 1000 and discard the remainder. You do not have to do it by hand here: paste a 13-digit value and the results include both “As Unix seconds” and “As Unix milliseconds”, ready to copy. That makes it easy to compare values that were recorded in different units.