What Is a Unix Timestamp?
A Unix timestamp, also called epoch time or POSIX time, is the number of seconds that have passed since January 1, 1970 at 00:00:00 UTC. That moment is the Unix epoch. Timestamp 0 is the epoch itself, 1700000000 is November 14, 2023 at 22:13:20 UTC, and negative numbers count backwards into the 1960s and earlier.
Programmers use timestamps because one integer is easy to store, sort, compare, and do arithmetic on. Subtracting two timestamps gives you a duration in seconds. Adding 86,400 moves you forward exactly one day. And because the count starts from a fixed moment in UTC, the number doesn’t depend on any time zone.
This converter works in both directions: paste a timestamp to get a readable date, or paste a date to get its timestamp. For a gentler introduction, read our guide Understanding Unix Timestamps.
How to Use the Timestamp Converter
- Paste a timestamp or a date into the input. Timestamps can be in seconds, milliseconds, microseconds, or nanoseconds, with an optional minus sign or decimal fraction (
1700000000.5). Dates can be ISO 8601 (2023-11-14T22:13:20Z) or plain English (November 14, 2023). - Press Convert or
Ctrl+Enter. The result shows the timestamp in seconds and milliseconds, the date in UTC, ISO 8601, and your local time zone, how long ago (or how far ahead) it is, and a year/month/day/time breakdown in local time. - Click Current Timestamp to load the current Unix time. If you have no saved input, the converter shows it as soon as the page opens.
- Copy the result with the Copy button or
Ctrl+Shift+C, and clear the input withCtrl+L.
How the Converter Detects Seconds, Milliseconds, and Nanoseconds
Different systems count time in different units, and the raw number doesn’t say which one it uses. The converter reads the number of digits in the integer part and picks the unit that gives a sensible date. The unit it chose is printed as the first line of the result.
| Digits | Read as | Example | Typical source |
|---|---|---|---|
| up to 11 | Seconds | 1700000000 | Unix tools, PHP, Python, JWT, most APIs |
| 12–14 | Milliseconds | 1700000000000 | JavaScript, Java, Kafka, Elasticsearch |
| 15–17 | Microseconds | 1700000000000000 | Go UnixMicro(), BigQuery UNIX_MICROS() |
| 18–19 | Nanoseconds | 1700000000000000000 | Go UnixNano(), Python time.time_ns(), InfluxDB, OpenTelemetry |
Any plain number is treated as a timestamp, so 0, 86400, and -86400 (the last day of 1969) all work. To convert a year, type a full date like 2023-01-01 instead of 2023. Nanosecond input is read as a digit string, so a 19-digit value keeps its precision, and the result is shown to the millisecond.
Time Zones: Why a Converted Date Can Be Hours Off
A timestamp is one instant. Time zones only matter when you turn that instant into a calendar date, or when you parse a date string that doesn’t say which zone it’s in. That second case is where most off-by-a-few-hours bugs come from. JavaScript, and this converter, follow the ECMAScript rules:
2023-11-14(a date with no time) is read as midnight UTC.2023-11-14T22:13:20(a date and time with no offset) is read as your local time.2023-11-14T22:13:20Zor2023-11-14T22:13:20+02:00is unambiguous.
When the converter applies one of the first two rules, it says so in the result. Most other languages give no such warning. Python’s datetime.timestamp() assumes local time for a naive datetime, and MySQL’s FROM_UNIXTIME() formats in the session time zone. If you need a portable value, always include Z or an explicit offset.
Common Timestamp Mistakes
- A date in the year 55,000. You passed milliseconds to something that expects seconds. Python fails outright with
ValueError: year 55840 is out of range. Divide by 1000. - A date in January 1970. The opposite mistake: seconds passed where milliseconds are expected.
new Date(1700000000)in JavaScript gives January 20, 1970. Multiply by 1000. - A month that’s off by one. JavaScript’s
getMonth()counts from 0, so November is 10. The converter’s breakdown shows the calendar month number (11) and its name. - Naive UTC datetimes in Python.
datetime.utcfromtimestamp()returns a datetime with no time zone attached, which later code easily treats as local time. It’s deprecated since Python 3.12. Usedatetime.fromtimestamp(ts, tz=timezone.utc). - Lost nanosecond precision. JavaScript numbers are exact only up to 9,007,199,254,740,991 (16 digits).
JSON.parseturns the nanosecond value 1700000000123456789 into 1700000000123456800. Send 19-digit timestamps as strings, or parse them withBigInt. - Milliseconds in a 32-bit column. A millisecond timestamp doesn’t fit a 32-bit
INT. UseBIGINT, or a native timestamp type.
Get and Convert Timestamps in Code
| Language | Current time (seconds) | Timestamp → date |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) | new Date(ts * 1000) |
| Python | int(time.time()) | datetime.fromtimestamp(ts, tz=timezone.utc) |
| PHP | time() | gmdate('c', $ts) |
| Java | Instant.now().getEpochSecond() | Instant.ofEpochSecond(ts) |
| Go | time.Now().Unix() | time.Unix(ts, 0).UTC() |
| C# | DateTimeOffset.UtcNow.ToUnixTimeSeconds() | DateTimeOffset.FromUnixTimeSeconds(ts) |
| PostgreSQL | EXTRACT(EPOCH FROM now()) | to_timestamp(ts) |
| MySQL | UNIX_TIMESTAMP() | FROM_UNIXTIME(ts) |
| Shell (Linux) | date +%s | date -u -d @ts |
| Shell (macOS) | date +%s | date -u -r ts |
To go the other way, from a date to a timestamp, parse the date with an explicit zone and read its epoch value: Date.parse('2023-11-14T22:13:20Z') / 1000 in JavaScript, Instant.parse(...).getEpochSecond() in Java, strtotime('2023-11-14 22:13:20 UTC') in PHP.
The Year 2038 Problem
Many older systems store Unix time in a signed 32-bit integer. Its maximum value, 2,147,483,647, is January 19, 2038 at 03:14:07 UTC. One second later the counter overflows to −2,147,483,648, and the date jumps back to December 13, 1901.
Modern operating systems and languages use a 64-bit time value, which lasts about 292 billion years. The risk that’s left sits in 32-bit embedded devices, old binary file formats, and database columns. MySQL’s TIMESTAMP type, for example, still ends at 2038-01-19 03:14:07 UTC. Anything that schedules dates far in advance, like 30-year loans or 20-year root certificates, hits the limit first. Paste 2147483647 into the converter to see the exact cutoff.
Unix Timestamps vs ISO 8601 Dates
| Unix timestamp | ISO 8601 string | |
|---|---|---|
| Example | 1700000000 | 2023-11-14T22:13:20Z |
| Human-readable | No | Yes |
| Time zone | Always UTC by definition | Explicit offset, or ambiguous if omitted |
| Sorting | Numeric, always correct | Correct only with the same format and offset |
| Size | 4–8 bytes as an integer | 20+ characters |
| Pitfall | Seconds vs milliseconds | Missing offset |
Use timestamps where a spec requires them or where you compare and sort a lot. Use ISO 8601 (or its stricter profile, RFC 3339) in APIs and config files that people read. Either way, store instants in UTC and convert to local time only when you display them.
Where You’ll Run Into Unix Timestamps
- JWTs. The
exp,iat, andnbfclaims are seconds since the epoch. Decode a token with the JWT Decoder, then pasteexphere to see exactly when it expires. - API responses and headers. Stripe’s
createdfields and GitHub’sx-ratelimit-resetheader are Unix seconds. Slack message IDs like1700000000.123456are seconds with a microsecond fraction, which the converter reads directly. - Logs and schedulers. Servers, queues, and observability tools stamp events in seconds, milliseconds, or nanoseconds. Pair the converter with the Cron Expression Builder when you’re checking when a job ran against when it was scheduled.
- IDs with a clock inside. A MongoDB ObjectId starts with a 4-byte Unix timestamp in hex: convert its first 8 hex characters with the Number Base Converter and paste the decimal here. UUIDv7 and ULID put a millisecond timestamp in their first 48 bits.
Your Data Stays in Your Browser
The converter runs entirely in JavaScript in your browser. Nothing you paste is uploaded or logged. That matters when the timestamp comes from a production log line or a token claim you’d rather not paste into a random website.