Timestamp Converter
Convert Unix timestamps to human-readable dates and back, in seconds or milliseconds, in UTC or your local time zone.
About Timestamp Converter
A Unix timestamp counts seconds since 1 January 1970 UTC. It is how most databases, log files and APIs store time, and it is completely unreadable at a glance. This tool converts in both directions and shows the result in several formats at once.
Seconds and milliseconds are both supported, and the unit is auto-detected — a ten-digit number is seconds, a thirteen-digit number is milliseconds. Getting this wrong is the classic bug: interpreting milliseconds as seconds throws you roughly fifty thousand years into the future, which is at least an obvious failure rather than a subtle one.
Every conversion is shown in UTC, in your local time zone, and as an ISO 8601 string, alongside a relative description such as 'three hours ago'. A live clock shows the current timestamp, which is handy when you need a value to paste into a test.
How to use it
- 1Paste a timestamp to convert it into readable dates.
- 2Or pick a date and time to get the timestamp for it.
- 3Check both the UTC and local readings — they differ by your offset.
- 4Copy whichever format you need.
Common uses
- Reading a timestamp out of a log file or database row
- Building a test fixture that needs a specific point in time
- Checking whether a token or cache entry has expired
- Debugging a time zone bug by comparing UTC against local
Frequently asked questions
Seconds or milliseconds — how do I tell?
By length. A current timestamp in seconds has ten digits; in milliseconds it has thirteen. The tool detects this automatically, but you can override it. JavaScript's Date.now() returns milliseconds while most Unix tooling and databases use seconds, which is exactly where the confusion starts.
Why does my timestamp show a different time than expected?
Almost always a time zone difference. A Unix timestamp is an absolute instant with no time zone attached — the same value renders as different wall-clock times depending on where you are. Compare the UTC row against the local row to see your offset.
What is the year 2038 problem?
Systems storing timestamps in a signed 32-bit integer overflow on 19 January 2038 and wrap to a negative number, reading as 1901. Anything using 64-bit timestamps, which includes all modern platforms, is unaffected. This tool handles dates far beyond that.
Can it handle dates before 1970?
Yes. Timestamps before the epoch are negative, and the tool converts them correctly in both directions.