Guide
Unix time explained: epoch, milliseconds, and timezones
What a Unix timestamp is, how seconds vs milliseconds differ, how timezones fit in, and the 2038 problem — with a live converter to follow along.
If you have ever seen a value like 1700000000 in a log line, an API response, or a database
column and wondered what date it represents, you have met Unix time. It is the most common way
software stores a moment in time. Paste any timestamp into the converter above to turn it into a
readable date as you read.
What a Unix timestamp actually is
A Unix timestamp is a single number: the count of seconds since the Unix epoch, which is
midnight UTC on 1 January 1970. So 0 is the epoch itself, 60 is one minute after it, and
1700000000 is 14 November 2023, 22:13:20 UTC.
Storing time as one integer is appealing because it is compact, easy to compare (later moments are simply larger numbers), and free of timezone ambiguity — the count is always measured from UTC.
Seconds vs milliseconds
The single most common source of confusion is the unit:
- Seconds — the classic Unix timestamp. Today's values are 10 digits (around 1.7 billion).
- Milliseconds — 1000× larger, 13 digits. JavaScript's
Date.now()and many web APIs use this.
A quick rule of thumb: a 10-digit number is seconds, a 13-digit number is milliseconds. To convert milliseconds to seconds, divide by 1000. The converter above detects which one you pasted and shows both, so you never have to guess.
Where timezones come in
Because a timestamp is counted from the UTC epoch, the timestamp itself has no timezone. The same instant is the same number in Tokyo and in New York. Timezones only appear when you format the timestamp into a human date — that is when "22:13 UTC" becomes "17:13 in New York". The converter shows the UTC value and a timezone-adjusted local value side by side so the difference is obvious.
The year 2038 problem
Older systems stored the timestamp in a signed 32-bit integer, which can only count up to 2,147,483,647 — a value reached on 19 January 2038. Past that point the number overflows and wraps to a negative value, mis-reading the date as 1901. The fix is simply to store the timestamp as a 64-bit integer, which pushes the limit hundreds of billions of years into the future. Most modern languages and databases already do this, but it is worth checking on legacy systems.
Try it
Paste a timestamp (in seconds or milliseconds) or a date into the tool above to convert between the two. It is handy for reading log timestamps, checking token and cookie expiry, and turning API epoch fields into dates you can actually read.