Unix Timestamp Converter
Convert Unix timestamps to human-readable dates and vice versa.
Seconds or milliseconds: the first thing to check
A Unix timestamp counts time from 1 January 1970 UTC, but two units are in common use and mixing them is the single most frequent timestamp bug. Unix tools, most APIs and the exp claim in a JWT use seconds. JavaScript, Java and many logging stacks use milliseconds.
You can tell them apart by length. A current timestamp in seconds has 10 digits; in milliseconds it has 13. Feeding a millisecond value to a seconds-based parser produces a date tens of thousands of years in the future, and the reverse produces a date in January 1970: both are unmistakable once you know to look for them. A date displayed as 1970 in a bug report almost always means a null or zero timestamp reached the formatter.
Reading a timestamp out of a log file
Paste the number above to get a readable date. Two things are worth knowing while doing it. Epoch time is always UTC by definition, there is no timezone stored in the number, so any local time you see has been converted for display, and the conversion is where errors enter. And a timestamp can be negative, which represents a date before 1970; negative values appearing in a modern system usually mean an uninitialised field rather than a genuine historical date.
Timestamp values worth having in your test data
| Value | Meaning | What it tends to expose |
|---|---|---|
0 | 1 Jan 1970 UTC | Null treated as zero; dates rendered as 1970 |
-1 | Just before the epoch | Unsigned assumptions, sorting errors |
2147483647 | 19 Jan 2038 UTC | The 32-bit signed overflow |
2147483648 | One second later | Wraps to 1901 on 32-bit systems |
1709164800 | 29 Feb 2024 UTC | Leap day handling |
| 13-digit value | Milliseconds | Unit confusion in the parser |
| Far-future value | Year 10000 and beyond | Formatters that assume four-digit years |
The 2038 problem, in practice
A signed 32-bit integer cannot hold a timestamp past 03:14:07 UTC on 19 January 2038; the next second wraps to 1901. Most modern platforms use 64-bit time and are unaffected, but the value is still worth testing today because it appears long before 2038 in ordinary features: a 20-year mortgage term, a certificate expiry, a subscription set far in the future, a sort that puts a wrapped date first. Embedded devices and older database columns are where it still bites.
Why a timestamp shows the wrong time
- Unit mismatch: seconds read as milliseconds or the reverse. Check the digit count first.
- Double conversion. A UTC timestamp converted to local time twice is off by the offset, and the size of the error changes with daylight saving.
- The server and the client are in different timezones and one of them formatted the value before sending it.
- The value was stored as a local time string and later parsed as UTC, losing the offset entirely.
- Clock skew between hosts, which shows up as tokens that expire early or events that appear out of order.
Conversion happens in your browser, so timestamps pulled from an internal log stay on your machine.
Frequently asked questions
How do I know whether a timestamp is in seconds or milliseconds?
Count the digits. A current timestamp is 10 digits in seconds and 13 in milliseconds. If the converted date lands in 1970 you were given milliseconds and parsed seconds; if it lands tens of thousands of years ahead, the reverse.
Does a Unix timestamp have a timezone?
No. It is always the number of seconds since the epoch in UTC. Any timezone you see is applied at display time, which is why the same stored value can legitimately show two different wall-clock times to two users.
What is the year 2038 problem?
A signed 32-bit integer overflows at 03:14:07 UTC on 19 January 2038 and wraps to 1901. Modern 64-bit systems are unaffected, but the value still belongs in test data because far-future dates occur in ordinary features such as long subscriptions and certificate expiries.
Why do timestamps sometimes appear as 1970?
Because a null, empty or zero value reached a date formatter. It is one of the most recognisable defects there is: a date of 1 January 1970 in a user interface nearly always means missing data rather than a real date.
Do Unix timestamps account for leap seconds?
No. Unix time treats every day as exactly 86,400 seconds and ignores leap seconds, so it is not a true count of elapsed physical seconds. This rarely matters in application testing but does matter in systems that measure precise intervals.
Can a Unix timestamp be negative?
Yes, representing dates before 1970. It is valid and historical data legitimately uses it, but a negative value in a modern application usually indicates an uninitialised field or an arithmetic error, so it is worth flagging when you see one.