Unix Timestamps Explained: Seconds, Milliseconds and 2038
Logs, databases, APIs and JWTs store time as a single number: seconds since the start of 1970 in UTC. Most bugs come from mixing up seconds and milliseconds, or from time zones being applied twice.
The definition
Unix time counts the seconds elapsed since 1970-01-01 00:00:00 UTC (the “epoch”), ignoring leap seconds. It is the same number everywhere on Earth at the same moment — time zones only matter when you display it.
Seconds or milliseconds?
| Digits (today) | Unit | Typical source |
|---|---|---|
| 10 | seconds | Unix tools, PHP time(), Python time.time() (with decimals), JWT exp/iat |
| 13 | milliseconds | JavaScript Date.now(), Java System.currentTimeMillis() |
| 16 | microseconds | some databases and tracing systems |
| 19 | nanoseconds | Go time.UnixNano(), some logs |
Timestamp Converter detects the unit by length and shows the date in UTC and your local time.
Time zone pitfalls
- Store and transmit UTC timestamps; convert to local time only for display.
- A date string without an offset (“2026-03-29 02:30”) is ambiguous — it may not even exist locally on a daylight-saving change day.
- Use ISO 8601 with an offset (“2026-03-29T02:30:00Z”) when you need text.
The year 2038 problem
Systems that store Unix time in a signed 32-bit integer can count only up to 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. One second later the value wraps to a negative number (December 1901). Modern 64-bit systems are not affected, but embedded devices, old file formats and database columns defined as 32-bit integers can be. Check any INT timestamp columns and long-lived devices now.