Unix Timestamps Explained: Seconds, Milliseconds and the Year 2038
A Unix timestamp is just a number of seconds, and it is how a large share of the world's software agrees on "when". Here is how to read one, convert it, and avoid the classic mistakes.
What a Unix timestamp is
A Unix timestamp (or epoch time) counts the seconds that have passed since 00:00:00 UTC on 1 January 1970, known as the Unix epoch. For example, 0 is that exact moment, and 1700000000 is 22:13:20 UTC on 14 November 2023.
Its appeal is simplicity: a single integer, independent of time zone, easy to compare, sort and subtract. To find out how long something took, subtract two timestamps. That's why databases, log files, APIs, JWT tokens and file systems store times this way.
Seconds or milliseconds?
The number of digits tells you which unit you have. As of the 2020s:
- 10 digits (e.g.
1700000000) → seconds. Common in Unix tools, PHP, Python'stime.time()(as a float) and JWT claims. - 13 digits (e.g.
1700000000000) → milliseconds. Used by JavaScript'sDate.now()and Java. - 16 digits → microseconds, and 19 digits → nanoseconds, seen in some databases and Go.
The most common bug is treating milliseconds as seconds: the date comes out tens of thousands of years in the future. If your converted date looks like the year 55,000, divide by 1000.
Time zones
A timestamp itself has no time zone; it identifies one instant that is the same everywhere. Time zones only come into play when you display it. The same timestamp shows as 22:13 in London and 17:13 in New York (winter). This is a strength: store timestamps in UTC and convert only for display, and you avoid most daylight-saving headaches.
Converting by hand and in code
A rough head-calculation: 86,400 seconds in a day, 31,536,000 in a 365-day year. Divide by 86,400 to get days since 1970.
- JavaScript:
new Date(1700000000 * 1000).toISOString()(the constructor takes milliseconds) andMath.floor(Date.now() / 1000)for the current time in seconds. - Python:
datetime.fromtimestamp(1700000000, tz=timezone.utc)andint(time.time()). - Linux / macOS shell:
date -u -d @1700000000on Linux;date -u -r 1700000000on macOS. - PostgreSQL:
to_timestamp(1700000000).
If you'd rather not write code, the converter does both directions: paste a timestamp to see the date in UTC and your local time zone, or pick a date and get the timestamp.
Leap seconds
Unix time ignores leap seconds. Every day is exactly 86,400 seconds long, and during a leap second the clock effectively repeats or smears a second. For nearly all applications this is irrelevant, but it means Unix time isn't a perfectly linear count of physical seconds.
The year 2038 problem
Many older systems store the timestamp as a signed 32-bit integer, whose maximum value is 2,147,483,647. That number of seconds after the epoch is 03:14:07 UTC on 19 January 2038. One second later it overflows and wraps to a negative number, which reads as December 1901.
Modern systems use 64-bit integers, which will not overflow for about 292 billion years, and most current operating systems and languages have already switched. The risk remains in old embedded devices, legacy databases with 32-bit fields, and file formats that were never updated. If you design a schema now, use a 64-bit type.
Dates before 1970
Negative timestamps represent dates before the epoch: -86400 is 31 December 1969. Support for them varies between languages and databases, so test before relying on it.
Frequently asked questions
What is the current Unix timestamp?
The converter shows the live current value in seconds and milliseconds.
Does a Unix timestamp include a time zone?
No. It always refers to UTC. Time zones apply only when converting to a readable date.
Why is 1 January 1970 the starting point?
The Unix developers chose a recent round date when they defined the system in the early 1970s. It became the convention.
How do I add a day to a timestamp?
Add 86,400 seconds. Be careful with daylight saving in local time; a local "day" is sometimes 23 or 25 hours long.