If you have ever opened a log file, an exported spreadsheet, or an API response and found a plain ten-digit number where a date should be, you have met a Unix timestamp. It looks like a mistake. It is not. It is simply time written in the form computers find easiest to work with: a single count of seconds.
Once you know the one rule behind it, that number stops being mysterious — and you can convert it back to a date in seconds.
What a Unix timestamp actually is
A Unix timestamp, also called epoch time or POSIX time, is the number of seconds that have passed since 00:00:00 UTC on 1 January 1970. That starting moment is called the Unix epoch.
So a timestamp is not a date or a clock reading. It is a distance from a fixed point: count that many seconds forward from the epoch and you arrive at the moment it describes. The timestamp 0 is the epoch itself; 86,400 — the seconds in a day — is exactly one day later.
This is why computers love the format: comparing two moments is a simple subtraction, sorting events is sorting numbers, and a single integer is compact and unambiguous in a way that a written date, with its formats and time zones, is not.
Why 1 January 1970?
There is nothing cosmically special about 1 January 1970. Unix was under development in the late 1960s and early 1970s, and its engineers needed a single reference point to measure time from. They picked a recent, round date, and the convention stuck, was standardised in POSIX, and spread far beyond Unix — which is why a Linux log file, a database, and a JavaScript app can all agree on what the same number means.
How to read a timestamp in three seconds
When a long number lands in front of you, run through three quick checks before anything else:
1. Count the digits. Around ten digits means seconds. Around thirteen digits means milliseconds — thousandths of a second. This one check prevents most timestamp mistakes.
2. Check the sign. A positive number is after 1970; a negative number is before it. Negative timestamps are legal, just uncommon in everyday data.
3. Remember it is UTC-based. The instant is fixed; the date you read off it depends on the time zone you convert it into.
That is really the whole reading method. Everything else — conversion, time zones, the Year 2038 problem — is detail built on top of it.
Seconds vs milliseconds: the ×1,000 trap
The single most common timestamp bug is a units mix-up. The original Unix convention counts seconds, and most server-side systems, databases, and command-line tools still do. But JavaScript works in milliseconds: its Date.now() returns milliseconds since the epoch, and Java’s System.currentTimeMillis() does the same. For a date in the 2020s, that is a thirteen-digit number instead of ten.
The two are easy to confuse and easy to fix. If your number has thirteen digits and the date it produces lands thousands of years in the future, you almost certainly have milliseconds. Divide by 1,000 and convert again. If you feed a seconds value into code that expects milliseconds, you will get a date in January 1970, because the code reads your ten-digit number as a much smaller count of milliseconds.
A concrete example: 1,700,000,000 in seconds is 14 November 2023. Add three zeros — 1,700,000,000,000 milliseconds — and it is the same moment. The digits are nearly identical; the unit changes everything.
Time zones: a timestamp has none
This point trips people up more than any other, so it is worth stating plainly: a Unix timestamp carries no time zone, because it does not need one. It identifies one instant. When you convert that instant into a readable date, the converter applies a time zone to display it — and different zones will show different wall-clock times for the same instant.
Take 1,700,000,000, which is 22:13:20 UTC on 14 November 2023. Ahead of UTC it shows as a later clock time that evening; behind UTC, an earlier one. Neither display is wrong — the timestamp never changed, only the label put on it.
Two practical consequences follow: people in different time zones comparing timestamps are comparing the same thing, and if a converted date looks a few hours “wrong,” check the display time zone before assuming the timestamp is broken. Unix time also ignores leap seconds, so each Unix day is exactly 86,400 seconds long.
Worked examples: five timestamps decoded
All conversions below are in UTC, so they can be checked against any converter without a time-zone argument:
| Unix timestamp | Date and time (UTC) | What it shows |
|---|---|---|
| 0 | 1 January 1970, 00:00:00 | The epoch itself |
| −86,400 | 31 December 1969, 00:00:00 | One day before the epoch (negative) |
| 946,684,800 | 1 January 2000, 00:00:00 | The turn of the millennium |
| 1,700,000,000 | 14 November 2023, 22:13:20 | A typical modern timestamp |
| 2,147,483,647 | 19 January 2038, 03:14:07 | The largest signed 32-bit value |
Notice the pattern: adding 86,400 moves the date forward exactly one day. The same idea works in reverse. Midnight UTC on 1 January 2025 is 1,735,689,600; midnight UTC on 1 January 2026 is 1,767,225,600. Subtract the two and you get 31,536,000 seconds — exactly 365 days.
Where you meet Unix timestamps
You do not have to be a programmer to run into them. They appear in log files and analytics exports, in databases (where integer times sort and filter quickly), in APIs (which commonly return epoch seconds), and in token or session expiry (where a “valid until” timestamp is compared against the current time). In each case the fix is the same: convert it, check the unit first, and check the display time zone second.
The Year 2038 problem
There is one genuine limit worth knowing about. Older systems store a timestamp in a signed 32-bit integer, which can hold values up to 2,147,483,647. Counting seconds from 1970, that ceiling is reached at 03:14:07 UTC on 19 January 2038. One second later, the counter overflows and wraps to a large negative number, which such a system would read as a date back in 1901.
That is the Year 2038 problem, the same kind of structural issue as the Year 2000 problem: a fixed-width field that seemed roomy when designed eventually runs out. The fix — store time in a 64-bit integer instead — is already standard in most modern systems, so 2038 is a real deadline for old embedded systems and unmaintained code, not a reason to distrust timestamps in general.
How to convert a timestamp
The fastest way is a converter, and the steps are the same whichever one you use: paste the timestamp and confirm the unit (ten digits means seconds, thirteen means milliseconds); if it is milliseconds and your converter works in seconds, divide by 1,000 first; read the resulting date, noting which time zone it was displayed in; and to go the other way, enter a date and time and copy the timestamp it returns.
Manage My Tools’ own Unix Timestamp Converter works exactly this way, in both directions: paste a timestamp to see its date, or enter a date and time to get its timestamp, with the current timestamp ticking live at the top of the page. One honest limit: it works in seconds, not milliseconds. A thirteen-digit value pasted as-is will convert to a date far in the future — divide by 1,000 first and convert the result. That is also why the tool’s sample value is 1700000000, the ten-digit timestamp decoded above.
In code, the pattern is short. In JavaScript, multiply seconds by 1,000 first, because Date expects milliseconds: new Date(1700000000 * 1000) gives the November 2023 date. In Python, datetime.datetime.fromtimestamp(1700000000, datetime.timezone.utc) gives the same moment directly in seconds.
Common mistakes
- Pasting a thirteen-digit value into a seconds converter. The date lands thousands of years ahead. Divide by 1,000 and try again.
- Treating the converted date’s time zone as part of the timestamp. The timestamp is zone-free; only the display has a zone.
- Reading 0 or a 1970 date as proof the data is corrupt. It may be — a missing value often defaults to 0 — but 0 is also a valid timestamp for the epoch itself. Check whether the field was ever filled before assuming corruption.
- Assuming ten digits always means seconds. For dates in the 2020s it does, but a very old date in milliseconds or a far-future date in seconds can blur the digit-count rule. If the converted date looks wrong, the unit is still the first thing to check.
- Forgetting that calendar gaps and instants are different questions. A timestamp answers “when did this happen?”; if you need “how many days are there between two dates?”, that is a calendar calculation, and our article on how many days between two dates walks through the inclusive-versus-exclusive counting that trips people up there.
Frequently asked questions
Is a Unix timestamp the same as epoch time?
Yes, in everyday usage. “Unix timestamp,” “epoch time,” and “POSIX time” all refer to the same count of seconds since 1 January 1970, 00:00:00 UTC. Other systems have their own epochs, but unqualified, “epoch time” almost always means Unix time.
Does a Unix timestamp include a time zone?
No. A timestamp names a single instant, and the same instant is displayed with different clock times in different zones. Convert the timestamp and choose the zone for display; the stored number does not change.
Why do buggy programs show dates in 1970?
Because a missing or zeroed value defaults to 0, which is the epoch: 1 January 1970. A 1970 date in modern data usually means a field was empty, or seconds were fed to code expecting milliseconds.
Is a ten-digit timestamp always in seconds?
For dates from 2001 to 2286, yes in practice. Outside that span the digit-count shortcut gets less reliable, so check the unit against the result.
Will timestamps break in 2038?
Only on systems that still store time as a signed 32-bit integer. Modern 64-bit systems are unaffected; the risk is specific to old or embedded systems that have never been updated.
Try it yourself
The next time a long number shows up where a date should be, count the digits, check the unit, convert, and check the display time zone — then try it: paste the number into the Unix Timestamp Converter and see the date it was hiding. For neighbouring jobs, see the Date & Time Tools collection and the all-tools page.
For deeper background, see Wikipedia’s article on the computing epoch: Epoch (computing).