Unix Timestamps: Seconds, Milliseconds, 2038
A Unix timestamp counts time since 1970-01-01 UTC. Tell seconds from milliseconds, convert to dates, avoid time zone bugs and understand the 2038 limit.
A Unix timestamp is the number of seconds that have passed since 00:00:00 UTC on 1 January 1970, known as the Unix epoch. It is a single number with no time zone, which makes it easy to store, compare and sort, and easy to misread when units or zones get mixed up.
Convert any value to a readable date, or the other way around, with the timestamp tool.
Unix Timestamp ConverterConvert a Unix timestamp to a readable date or the other way round. The unit is detected automatically and every result shows its time zone.Seconds or milliseconds?
The same instant can be written in different units depending on the language or API. Counting digits is the quick way to tell them apart.
| Unit | Digits today | Example | Common source |
|---|---|---|---|
| Seconds | 10 | 1700000000 | Unix tools, many APIs, JWT claims |
| Milliseconds | 13 | 1700000000000 | JavaScript Date.now(), Java |
| Microseconds | 16 | 1700000000000000 | Some databases and logging systems |
1700000000 is 14 November 2023 at 22:13:20 UTC.
The two classic mistakes
- Milliseconds read as seconds: the date lands tens of thousands of years in the future.
- Seconds read as milliseconds: the date lands in January 1970, only a few weeks after the epoch.
If you see 1970 in a UI, a missing * 1000 or / 1000 is the first suspect.
Time zones
A timestamp identifies one instant everywhere on Earth. Only the formatting depends on a time zone. 1700000000 is the same moment in Tokyo and in New York; it is simply displayed as different clock times.
Store and transmit timestamps (or ISO 8601 strings with an explicit offset such as 2023-11-14T22:13:20Z), and convert to a local time zone only at the edge, when showing the value to a person.
Converting in code
// seconds -> Date
new Date(1700000000 * 1000).toISOString();
// "2023-11-14T22:13:20.000Z"
// now, in seconds
Math.floor(Date.now() / 1000);
The year 2038 problem
Systems that store the timestamp in a signed 32-bit integer can hold at most 2,147,483,647 seconds, which is 19 January 2038 at 03:14:07 UTC. One second later the value wraps to a large negative number, which is interpreted as a date in 1901.
Modern 64-bit systems and languages are unaffected, with a range of hundreds of billions of years. The risk is concentrated in old embedded systems, legacy binary file formats and database columns declared as 32-bit integers. If you control a schema, use a 64-bit type or a proper timestamp column.
Leap seconds and negative values
Unix time ignores leap seconds: every day is treated as exactly 86,400 seconds. Negative timestamps are valid and represent instants before 1970.
Where timestamps show up
- JWT claims such as
expandiatare in seconds. - Log lines and API responses often use milliseconds.
- Scheduled jobs are defined by wall-clock fields rather than timestamps; the cron guide explains how those schedules are written.