Unix Timestamp Converter
Current Unix timestamp: (updates every second)
A Unix timestamp converter turns the number of seconds since 1 January 1970 (UTC) into a human-readable date — and converts a date back into a timestamp. Timestamps like 1704067200 show up everywhere: API responses, JWT tokens, database fields, and log files. Paste one into the tool to see the date instantly, or generate the current timestamp for your own code.
Timestamp → Date
Date → Timestamp
What a Unix timestamp actually is
A Unix timestamp (also called epoch time) is simply a count of seconds elapsed since 00:00:00 UTC on 1 January 1970, known as the epoch. Because it is a single integer with no time-zone information attached, it is unambiguous: 1704067200 means exactly 2024-01-01 00:00:00 UTC no matter where in the world you read it. That is why APIs, databases, and file formats prefer timestamps over formatted date strings — there is no locale, no format ambiguity, and sorting is just numeric comparison. Time zones only enter the picture when you convert a timestamp for display.
Seconds vs milliseconds: the classic bug
Pass a seconds value where milliseconds are expected and you get a date in January 1970; pass milliseconds where seconds are expected and you land tens of thousands of years in the future. Rule of thumb: around 1.7 billion means seconds, around 1.7 trillion means milliseconds. On this page, use the Unit dropdown to tell the tool which one you pasted — Seconds for a 10-digit value, Milliseconds for a 13-digit one. If the result looks absurd, the unit is wrong, not the number.
How to use it
- Paste a timestamp into the input and set the Unit dropdown to match it — Seconds for a 10-digit value like
1704067200, Milliseconds for a 13-digit value like1704067200000. Or press Use current time to fill in right now. - Read the result as GMT, ISO 8601, and your local time, plus the relative form ("3 days ago").
- To go the other way, use the Date → Timestamp panel: pick a date and time, choose which timezone it should be interpreted in, and copy the Unix timestamp in seconds and milliseconds.
What it expects
A Unix timestamp as a plain integer, with the Unit dropdown set to match: 10 digits for seconds (e.g. 1704067200) or 13 digits for milliseconds (e.g. 1704067200000). Decimal fractions are accepted too: 1704067200.5 means half a second past the whole-second value. Anything that is not numeric is rejected rather than guessed at.
Convert timestamps in code
The same conversion in the languages where it comes up most:
// JavaScript — Date expects milliseconds, so multiply seconds by 1000
new Date(1704067200 * 1000).toISOString();
// → "2024-01-01T00:00:00.000Z"
// Python — attach UTC explicitly to avoid local-time surprises
from datetime import datetime, timezone
datetime.fromtimestamp(1704067200, tz=timezone.utc)
// → datetime.datetime(2024, 1, 1, 0, 0, tzinfo=datetime.timezone.utc)
// PHP — set the timezone first, then format
date_default_timezone_set('UTC');
date('Y-m-d H:i:s', 1704067200);
// → "2024-01-01 00:00:00"
// Go — time.Unix takes seconds and nanoseconds
time.Unix(1704067200, 0).UTC().Format(time.RFC3339)
// → "2024-01-01T00:00:00Z"
// Bash — the @ prefix tells date the value is a timestamp
date -u -d @1704067200
// → Mon Jan 1 00:00:00 UTC 2024Going the other direction — date to timestamp — is the mirror operation: JavaScript's Date.parse("2024-01-01T00:00:00Z") / 1000, Python's datetime(2024,1,1,tzinfo=timezone.utc).timestamp(), or PHP's strtotime("2024-01-01 00:00:00 UTC").
Handy reference values
| Timestamp | Date (UTC) | Why it matters |
|---|---|---|
0 | 1970-01-01 00:00:00 | The epoch itself; a zero timestamp usually means "not set" |
1000000000 | 2001-09-09 01:46:40 | The "billion-second" milestone, common in test data |
1704067200 | 2024-01-01 00:00:00 | A clean recent reference for sanity-checking conversions |
2147483647 | 2038-01-19 03:14:07 | Maximum 32-bit signed timestamp — the Year 2038 limit |
Limitations
Timezone offsets for dates far in the past or future rely on your browser's built-in timezone database, which may not reflect historical changes to a region's timezone rules.
Negative timestamps and the Year 2038 problem
Timestamps before 1970 are negative numbers: -86400 is 1969-12-31 00:00:00 UTC. Most modern languages handle them, though some older databases and 32-bit systems do not. The better-known edge is the Year 2038 problem: 32-bit signed timestamps max out at 2147483647 (19 January 2038, 03:14:07 UTC) and wrap to negative values — the same class of bug as Y2K. New code using 64-bit integers is unaffected; check legacy 32-bit columns if you maintain old systems.
Frequently asked questions
- How do I convert a Unix timestamp to a date?
- Paste it into the Timestamp → Date panel above, set the Unit dropdown to Seconds or Milliseconds to match your value, and read the result as GMT, ISO 8601, or your local time. In your own code: JavaScript needs new Date(timestamp * 1000) because Date expects milliseconds, while Python uses datetime.fromtimestamp(timestamp, tz=timezone.utc).
- Why does my timestamp show a date in 1970 — or tens of thousands of years in the future?
- The Unit dropdown does not match your value. A 10-digit timestamp like 1704067200 is seconds; a 13-digit one like 1704067200000 is milliseconds. Seconds read as milliseconds land you in January 1970; milliseconds read as seconds land you tens of thousands of years out. Switch the Unit dropdown and the date snaps into place.
- What is the difference between a 10-digit and 13-digit timestamp?
- A 10-digit timestamp counts whole seconds since the epoch (for example 1704067200), while a 13-digit one counts milliseconds (1704067200000). Seconds are the classic Unix convention used by PHP, Python, and most databases; milliseconds are used by JavaScript, Java, and many JSON APIs. Current values sit around 1.7 billion for seconds and 1.7 trillion for milliseconds.
- What is the Year 2038 problem?
- Systems that store Unix timestamps as 32-bit signed integers run out of room on 19 January 2038 at 03:14:07 UTC, when the value 2147483647 overflows and wraps to a negative number — dates suddenly jump back to 1901. It is the same class of bug as Y2K. The fix is to store timestamps as 64-bit integers, which modern languages and databases already do by default.
- Can Unix timestamps be negative?
- Yes. Negative timestamps represent dates before 1 January 1970 — for example, -86400 is 31 December 1969. Most current programming languages handle them correctly, but some older databases, file formats, and 32-bit libraries reject or misinterpret negative values, so test explicitly if your data includes pre-1970 dates such as historical birth dates.
- Are Unix timestamps affected by time zones or daylight saving?
- No. A timestamp is an absolute count of seconds in UTC, so it is identical worldwide — time zones only matter when you convert it to a readable date for display. Daylight saving transitions never shift a timestamp itself; they only change which local clock time a given timestamp renders as. This is exactly why timestamps are preferred for storing moments in databases and APIs.
- Do Unix timestamps account for leap seconds?
- No. Unix time pretends every day has exactly 86,400 seconds and ignores leap seconds, so the timestamp drifts slightly from true astronomical time. For everyday software this is irrelevant, but systems that need precise sub-second alignment with UTC — such as scientific instrumentation or high-frequency trading — must handle leap seconds explicitly rather than relying on Unix timestamps.