How to Convert a Unix Timestamp to a Date (and Back)

To convert a Unix timestamp to a date, paste it into the Toolstik Unix Timestamp Converter, leave the unit on Auto-detect, and click Convert. You get ISO 8601, UTC, your local time, and a relative time such as "3 years ago". For example, 1700000000 is 2023-11-14T22:13:20.000Z. To go the other way, switch to the Date to timestamp tab, type a date like 2026-10-10T12:00:00Z, and click Convert again.

Step by step: timestamp to date

1. Open the Unix Timestamp Converter. The Timestamp to date tab is selected, with 1700000000 as the example.
2. Paste your number into Unix timestamp. Whole numbers, decimals (1700000000.5), and negative values (dates before 1970) all work. Commas and spaces inside the number don't.
3. Set Unit: Auto-detect (default), Seconds, or Milliseconds.
4. Click Convert or press Enter.
5. Read the results. With Auto-detect on, a line such as "Detected as seconds." confirms how the number was read. Below it are six fields, each with its own copy button: ISO 8601 (UTC), Unix seconds, Unix milliseconds, UTC, Your local time, and Relative.

Need the current time? Click Use current time. On this tab it fills in the current Unix time in seconds, switches Unit to Seconds, and shows the result right away.

Step by step: date to timestamp

1. Click the Date to timestamp tab.
2. Type a date into Date and time. ISO 8601 is the most reliable format, for example 2026-10-10, 2026-10-10T12:00:00Z, or 2026-10-10T12:00:00+05:00.
3. Click Convert. Read Unix seconds for most APIs and databases, or Unix milliseconds for JavaScript.

On this tab, Use current time fills in the current moment as an ISO string and converts it.

Parsing is done by your browser's Date.parse, so pay attention to time zones:

Formats like 03/04/2026 are ambiguous (March 4 or April 3?) and browser-dependent. Stick to ISO 8601 and include Z or an offset whenever the exact instant matters.

How Auto-detect decides between seconds and milliseconds

The rule in the code is simple: if the absolute value is 100,000,000,000 (1e11) or more, it's treated as milliseconds. Otherwise it's seconds.

• 1700000000 (10 digits) is read as seconds: 2023-11-14T22:13:20Z.
• 1700000000000 (13 digits) is read as milliseconds: the same instant.

Seconds wouldn't reach 1e11 until the year 5138, so for real-world dates this is safe. The edge case is small millisecond values. 10000000000 in milliseconds is late April 1970, but Auto-detect reads it as seconds (the year 2286). If you're working with durations or very early dates, pick Milliseconds yourself.

Microseconds and nanoseconds (16 and 19 digits, from Go, Python time.time_ns(), or some databases) aren't units in the tool. A microsecond value gets read as milliseconds and lands tens of thousands of years in the future. A nanosecond value is rejected as "outside the supported date range". Divide by 1,000 or 1,000,000 first.

Convert timestamps in code

All of these were checked against 1700000000, which should give 2023-11-14 22:13:20 UTC.

JavaScript, where Date works in milliseconds:

new Date(1700000000 * 1000).toISOString();          // "2023-11-14T22:13:20.000Z"
Math.floor(Date.now() / 1000);                      // current Unix seconds
Date.parse("2026-10-10T12:00:00Z") / 1000;          // 1791633600

Python:

from datetime import datetime, timezone

datetime.fromtimestamp(1700000000, tz=timezone.utc).isoformat()
# '2023-11-14T22:13:20+00:00'

int(datetime(2026, 10, 10, 12, 0, tzinfo=timezone.utc).timestamp())
# 1791633600

Always pass tz=timezone.utc. Without it, fromtimestamp returns your machine's local time, and utcfromtimestamp is deprecated as of Python 3.12.

SQL:

-- PostgreSQL
SELECT to_timestamp(1700000000);                              -- timestamptz
SELECT EXTRACT(EPOCH FROM TIMESTAMPTZ '2023-11-14 22:13:20+00');

-- MySQL (result is shown in the session time zone)
SELECT FROM_UNIXTIME(1700000000);

-- SQLite
SELECT datetime(1700000000, 'unixepoch');                     -- 2023-11-14 22:13:20

bash:

date +%s                                  # current Unix seconds
date -u -d @1700000000                    # GNU/Linux: Tue Nov 14 22:13:20 UTC 2023
date -u -r 1700000000                     # macOS/BSD: Tue Nov 14 22:13:20 UTC 2023
date -u -d '2023-11-14 22:13:20' +%s      # GNU/Linux: 1700000000

Troubleshooting

• Date shows January 1970. You passed seconds to something expecting milliseconds, usually new Date(seconds) in JavaScript. Multiply by 1,000.
• Date is tens of thousands of years in the future. The opposite: milliseconds were treated as seconds, or you have microseconds. Divide.
• Off by a few hours. A time-zone issue, not a conversion bug. Compare against ISO 8601 (UTC), then check whether your date string had an offset and whether your code formats in local time.
• Off by exactly one hour around March or November. Daylight saving time changed the local offset. The Unix value is right. Only the local display shifted.
• Negative number from a 32-bit system. You've hit Y2038. A signed 32-bit integer tops out at 2147483647 (2038-01-19T03:14:07Z), and one second later it wraps to -2147483648 (1901-12-13T20:45:52Z). Store timestamps in 64-bit integers.
• Leap seconds. Unix time ignores them. Every day is exactly 86,400 seconds, so the tool and these snippets never show a :60 second.

Where you'll meet timestamps

JWT claims exp, iat, and nbf are Unix seconds. Decode a token with the JWT Decoder, then paste exp here to see exactly when it expires. How to decode a JWT safely walks through that workflow, and JWT header vs payload vs signature explained covers what the other claims mean. API responses often include created_at fields, too: pretty-print the response in the JSON Formatter to find them. For every related utility in one place, see free developer tools online.