If you’ve worked with logs, databases or APIs, you’ve seen a number like 1700000000 standing in for a date. That’s a Unix timestamp, and understanding it removes a whole category of time-related bugs. Here’s the complete picture.
The same instant, two answers.
1700000000in our timestamp converter returns both lines at once:Local: 2023-11-15 06:13:20 UTC: 2023-11-14 22:13:20Note the dates differ — this instant falls on 14 November in UTC and 15 November in a UTC+8 timezone. That is deliberately shown side by side, because nearly every timestamp bug is somebody reading a local rendering and believing it was UTC. Ten digits means seconds; thirteen means milliseconds, and a seconds-based reader given milliseconds lands in the year 55,839.
What is a Unix timestamp?
A Unix timestamp is the number of seconds elapsed since the Unix epoch — 00:00:00 UTC on 1 January 1970. Because it’s counted from a fixed point in UTC, it’s a single absolute number that means the same thing everywhere on Earth, independent of time zone.
That property is exactly why systems love it: two servers in different countries can compare timestamps directly, with no time-zone math.
Seconds vs. milliseconds
This is the number-one source of confusion. Different platforms use different units:
- Seconds — a 10-digit number, e.g.
1700000000. Common in Unix tools, databases, and many APIs. - Milliseconds — a 13-digit number, e.g.
1700000000000. JavaScript’sDate.now()returns this.
A quick rule of thumb: 10 digits = seconds, 13 digits = milliseconds. If a date comes out around the year 1970, you probably passed milliseconds where seconds were expected (or vice versa). Our timestamp converter auto-detects the unit from the digit count, so you don’t have to guess.
Time zones and UTC
A timestamp itself has no time zone — it’s an absolute instant. The time zone only matters when you display it. The same timestamp 1700000000 is:
2023-11-14 22:13:20in UTC2023-11-15 06:13:20in UTC+8 (Taipei)
Both are the same moment, shown in different zones. When debugging, always confirm which zone a displayed time is in — our converter shows both your local time and UTC side by side to avoid mistakes.
Here is the same set of timestamps through our own timestamp converter. The machine that produced this table was set to UTC+8, which is why every local time runs eight hours ahead of the UTC one — and that offset is the entire point of showing both lines at once.
| Timestamp | What our converter shows |
|---|---|
0 | Local: 1970-01-01 08:00:00 UTC: 1970-01-01 00:00:00 |
1000000000 | Local: 2001-09-09 09:46:40 UTC: 2001-09-09 01:46:40 |
1700000000 | Local: 2023-11-15 06:13:20 UTC: 2023-11-14 22:13:20 |
1767225600 | Local: 2026-01-01 08:00:00 UTC: 2026-01-01 00:00:00 |
2147483647 | Local: 2038-01-19 11:14:07 UTC: 2038-01-19 03:14:07 |
2147483648 | Local: 2038-01-19 11:14:08 UTC: 2038-01-19 03:14:08 |
Converting in code
Most languages make conversion straightforward:
// JavaScript (milliseconds)
const now = Date.now(); // 1700000000000
const date = new Date(1700000000000); // Date object
const seconds = Math.floor(Date.now() / 1000);# Python (seconds)
import time
now = int(time.time()) # 1700000000
from datetime import datetime, timezone
dt = datetime.fromtimestamp(1700000000, tz=timezone.utc)Note how JavaScript works in milliseconds while Python’s time.time() returns seconds — another reason to keep the units straight.
The year 2038 problem (briefly)
Systems that store timestamps as a signed 32-bit integer will overflow on 19 January 2038. Modern systems use 64-bit integers, which pushes the limit hundreds of billions of years out, so it’s rarely a concern today — but it’s worth knowing why 64-bit time exists.
The last two rows are the 2038 boundary. 2147483647 is Local: 2038-01-19 11:14:07 UTC: 2038-01-19 03:14:07; add one second and our converter gives Local: 2038-01-19 11:14:08 UTC: 2038-01-19 03:14:08 without complaint. That is worth understanding precisely: the arithmetic is fine, because JavaScript holds the value in a double. The 2038 problem is not about arithmetic at all — it is about storage, a signed 32-bit integer that has no room for 2147483648. Anything reading that column as int wraps to a negative number and lands in 1901.
Quick conversions
Need to check a timestamp right now? Paste it into the free Unix timestamp converter to see the local and UTC date instantly, convert a date back to a timestamp, or copy the current timestamp. It runs in your browser — no connection required.