Timestamp Converter
Convert Unix timestamps (seconds or milliseconds) to human-readable dates and back. Auto-detects the unit, supports negative epochs, and shows UTC, GMT, and local.
Convert timestamps and dates
Auto-detect treats any value with absolute size 10^11 or larger as milliseconds. Negative values (pre-1970) are supported.
Result
Detected unit: seconds|Relative: last year
ISO 8601 (UTC)
2025-01-16T04:00:00.000Z
GMT string
Thu, 16 Jan 2025 04:00:00 GMT
Browser local
Thu Jan 16 2025 04:00:00 GMT+0
Unix seconds
1737000000
Unix milliseconds
1737000000000
Date breakdown
- Year
- 2025
- Month
- 1
- Day
- 16
- Weekday
- Thursday
- Hour
- 4
- Minute
- 0
- Second
- 0
Frequently Asked Questions about the Timestamp Converter
What is a Unix timestamp?
A Unix timestamp is the number of seconds (or milliseconds) since 00:00:00 UTC on 1 January 1970, called the Unix epoch. It is the storage format most databases, APIs, and log files use for points in time because it is timezone-free and sorts naturally as a number.
How does this tool know whether my number is seconds or milliseconds?
Any absolute value of 10^11 or larger is treated as milliseconds, anything smaller as seconds. That boundary maps to early 1973 in milliseconds versus the year 5138 in seconds, so real-world values never collide. You can override the choice with the unit dropdown.
Can I convert dates from before 1970?
Yes. Negative timestamps work in both directions. JavaScript stores time as a 64-bit floating-point number of milliseconds, so the 32-bit overflow that produces the year-2038 bug in some C systems does not apply here. The supported range is roughly +-285,000 years around the epoch.
Why does a date string without a Z still produce a UTC result?
If you paste '2026-01-15T10:30:00' the parser appends a Z and treats it as UTC. Without that rule the same input would silently shift by your machine's timezone offset, which is a common source of off-by-one-day bugs. Add an explicit offset like +02:00 or use the timezone dropdown when you want local time.
Is the year-2038 problem relevant to my code?
Only if you store timestamps as signed 32-bit integers in seconds. That column overflows on 19 January 2038. JavaScript, Python, modern PostgreSQL and MySQL all use 64-bit time and are unaffected. Audit any older C, embedded firmware, or legacy SQL tables that still use INT(11) or time_t for date fields.