Processed locally in your browser — not uploaded
Unix Timestamp Converter
Convert Unix timestamps in seconds, milliseconds, microseconds, or nanoseconds — detected automatically — into human-readable ISO 8601, UTC, Amman time (GMT+3), local browser time, and relative time expressions. Date strings convert back to epoch values. Runs entirely in your browser.
How to use
- Enter a Unix timestamp — seconds, milliseconds, microseconds, or nanoseconds, detected automatically — or a date string like an ISO 8601 timestamp.
- All representations update as you type: seconds, milliseconds, ISO 8601, UTC, your local time, Amman time, and relative time.
- Check the detected unit next to the results heading to confirm the value was read the way you intended.
- Click "Now" to load the current instant.
Understanding the output
Numeric input is classified by digit count: up to 11 digits is seconds, 12–14 is milliseconds, 15–17 is microseconds, and 18 or more is nanoseconds. Non-numeric input is parsed as a date string (ISO 8601 and most common formats).
Common issues & tips
- •Wrong date shown: compare the detected unit with your source system. JavaScript's Date.now() returns milliseconds, while Unix shells and Python's time.time() return seconds.
- •"Couldn't parse that value": the input isn't a valid Unix timestamp or a date format the browser recognizes.
- •A date-only string like "2024-01-01" is read as UTC midnight, but "2024-01-01T00:00" without an offset is read as your local time.
Seconds, milliseconds, microseconds, or nanoseconds?
A Unix timestamp counts time since 1970-01-01T00:00:00Z, but systems disagree on the unit. For current dates, the digit count gives it away:
| Digits | Unit | Example | Produced by |
|---|---|---|---|
| 10 | Seconds | 1700000000 | date +%s, Python int(time.time()), Go Unix(), PostgreSQL extract(epoch …) |
| 13 | Milliseconds | 1700000000123 | JavaScript Date.now(), Go UnixMilli() |
| 16 | Microseconds | 1700000000123456 | Go UnixMicro() |
| 19 | Nanoseconds | 1700000000123456789 | Go UnixNano(), Python time.time_ns() |
This converter classifies up to 11 digits as seconds, 12–14 as milliseconds, 15–17 as microseconds, and 18 or more as nanoseconds. That boundary means a 12-digit value such as 946684800000 is read as milliseconds (2000-01-01) rather than seconds in the year 31,969. Values are truncated to millisecond precision for display.
Getting and converting Unix timestamps in code
// JavaScript — Date works in millisecondsconst seconds = Math.floor(Date.now() / 1000);const date = new Date(1700000000 * 1000);date.toISOString(); // "2023-11-14T22:13:20.000Z"# Pythonimport timefrom datetime import datetime, timezoneseconds = int(time.time())datetime.fromtimestamp(1700000000, tz=timezone.utc) # 2023-11-14 22:13:20+00:00int(datetime(2024, 1, 1, tzinfo=timezone.utc).timestamp()) # 1704067200-- PostgreSQLSELECT to_timestamp(1700000000); -- timestamptzSELECT extract(epoch FROM timestamptz '2024-01-01 00:00:00+00'); -- 1704067200date +%s # current Unix time in secondsdate -u -r 1700000000 # macOS/BSD: timestamp → datedate -u -d @1700000000 # GNU coreutils (Linux): timestamp → dateAlways pass an explicit timezone when converting to a calendar date. Python's fromtimestamp without tz and PostgreSQL's timestamptz output both use the local or session time zone. References: Python datetime, PostgreSQL date/time functions, GNU coreutils: seconds since the Epoch.
Unix time gotchas
- Date-only strings are UTC; date-times without an offset are local. In JavaScript,
new Date("2024-01-01")is midnight UTC, butnew Date("2024-01-01T00:00")is midnight in the runtime's time zone — in Amman (UTC+3) that is2023-12-31T21:00:00.000Z. AddZor an explicit offset to remove the ambiguity. - Leap seconds are ignored. Unix time treats every day as exactly 86,400 seconds, and JavaScript's
Datefollows the same model, as the MDN Date reference notes. Subtracting two timestamps can therefore differ slightly from true elapsed time across a leap second. - The Year 2038 problem. A signed 32-bit integer tops out at
2147483647, which is2038-01-19T03:14:07Z. Systems that still store Unix time in 32 bits overflow one second later; use 64-bit integers or native timestamp types. - JavaScript's Date has a range. It represents up to ±8,640,000,000,000,000 ms from the epoch — the latest valid date is
+275760-09-13T00:00:00.000Z. Anything beyond that is an Invalid Date.
Frequently asked questions
- Does this support seconds, milliseconds, microseconds, and nanoseconds?
- Yes. The unit is detected from the digit count: up to 11 digits is seconds, 12–14 is milliseconds, 15–17 is microseconds, and 18 or more is nanoseconds. The detected unit is shown next to the results.
- Is my input uploaded anywhere?
- No. Timestamp parsing and formatting happen entirely in your browser.
- Why does new Date("2024-01-01") give a different time than new Date("2024-01-01T00:00")?
- JavaScript parses a date-only ISO string as UTC midnight, but a date-time string without an offset as local time. Add Z or an explicit offset such as +03:00 to make the meaning unambiguous.
- What is the Year 2038 problem?
- Systems that store Unix time as a signed 32-bit integer can count only up to 2147483647, which is 2038-01-19T03:14:07Z. One second later the value overflows. Storing timestamps as 64-bit integers or native date types avoids it.
- Do Unix timestamps include leap seconds?
- No. Unix time treats every day as exactly 86,400 seconds, and JavaScript's Date follows the same model, so leap seconds are ignored.