What a Unix timestamp is
A Unix timestamp is the number of seconds since midnight UTC on 1 January 1970 — the "epoch". It's timezone-free (always UTC) and easy to compare and sort, which is why it shows up in logs, databases, JWTs and APIs everywhere.
| Form | Example | Where |
|---|---|---|
| Seconds (10 digits) | 1700000000 | Unix, most APIs, JWT exp |
| Milliseconds (13 digits) | 1700000000000 | JavaScript Date.now(), Java |
Gotcha — seconds vs milliseconds. This is the most common timestamp bug. JavaScript works in milliseconds; Unix and most backends work in seconds. Feed seconds to new Date() and you'll land in 1970. Rule of thumb: 10 digits is seconds, 13 is milliseconds — this tool detects and labels which it read.
Converting in different languages
// JavaScript — works in milliseconds
Date.now(); // ms since epoch
new Date(1700000000 * 1000); // seconds → Date
# Python — seconds
import time, datetime
time.time()
datetime.datetime.fromtimestamp(1700000000, datetime.timezone.utc)
-- SQL (PostgreSQL)
SELECT to_timestamp(1700000000);A quick way to read one
Epoch 0 is 1970-01-01 00:00:00 UTC. The value 1700000000 is 14 November 2023; the same instant in milliseconds is 1700000000000. If a converted date lands in 1970 you fed seconds into something expecting milliseconds; if it lands tens of thousands of years out, you did the reverse.
ISO 8601, when you need text
When a human-readable date is required, ISO 8601 (2026-06-19T08:30:00Z) is the safe format: it sorts correctly as plain text and the trailing Z means UTC. Store and transmit in UTC, and convert to a local time zone only at the edge, when you display it.
Store UTC, display local
Almost every painful date bug traces back to mixing up when to use UTC and when to use a local zone. The rule that keeps you out of trouble: store and compute in UTC, and convert to a local time zone only at the very edge, when you show a time to a person. A Unix timestamp is already UTC by definition, which is exactly why it's the safe thing to put in a database or pass between services. The moment you store a "local" time without its zone, you've lost information you can't reliably get back, because the same wall-clock reading means a different instant in Tokyo and in New York.
Time zones are also not the fixed offsets people assume. They change with daylight saving, and those rules are political and get edited, which is why real systems lean on the IANA time-zone database (names like America/New_York) rather than hard-coding "UTC−5". Daylight saving even creates clocks that don't exist and clocks that happen twice: on a spring-forward night 2:30am simply never occurs, and on fall-back it occurs twice, so "2:30am local" can be ambiguous or impossible. Storing UTC sidesteps the whole mess.
Don't use the wall clock for a stopwatch
If you want to time how long an operation took, Date.now() is the wrong tool, even though it's the obvious one. The wall clock can jump — a network time sync nudges it, a user changes it, daylight saving shifts it — so subtracting two wall-clock readings can hand you a negative duration or a wild one. For measuring elapsed time, use a monotonic clock that only ever moves forward: performance.now() in the browser, time.monotonic() in Python. Wall clocks answer "what time is it"; monotonic clocks answer "how much time has passed", and those are genuinely different questions.
Should I store local time or UTC?
Store UTC and convert to a local zone only when displaying it. A local time without its time zone is ambiguous — the same reading is a different instant in different places — and daylight saving can make a local time occur twice or not at all.
Why shouldn't I use Date.now() to measure how long something took?
The wall clock can jump backward or forward (time syncs, manual changes, DST), giving wrong or negative durations. Use a monotonic clock — performance.now() in browsers, time.monotonic() in Python — which only moves forward.
How can I tell seconds from milliseconds at a glance?
Count the digits: a 10-digit value is almost always seconds, a 13-digit value is milliseconds. Mixing them up by a factor of 1000 is the most common timestamp bug.
Does it use my timezone?
The epoch itself is always UTC. The converter shows both the UTC time and your browser's local time so you can see the offset.
What's the 2038 problem?
Systems that store the timestamp as a signed 32-bit integer overflow on 19 January 2038. Modern systems use 64-bit timestamps and are fine for billions of years.
Is the current time fetched online?
No — it comes from your device clock, updating every second, with no network request.