Timestamp Converter
Convert Unix timestamps to ISO dates and human-readable time in one click.
What this tool does
Unix timestamps are integer counts of seconds (or milliseconds) since January 1, 1970, 00:00:00 UTC, the Unix epoch. They are the universal time format used in databases, APIs, logs, and file systems because they are timezone-independent and easy to compare. This tool converts between Unix timestamps and human-readable dates in any timezone, with support for both seconds and milliseconds.
The converter displays the date in your local timezone, UTC, and any custom timezone you specify. It also shows the ISO 8601 string, RFC 2822 string, and relative time (e.g., "2 days ago"). This is invaluable when debugging API responses, parsing log files, or coordinating events across distributed systems.
Usage Example
// Current timestamp in seconds
Math.floor(Date.now() / 1000)
// 1710504000
// Current timestamp in milliseconds (JavaScript convention)
Date.now()
// 1710504000000
// Convert timestamp to Date object
new Date(1710504000 * 1000)
// 2024-03-15T12:00:00.000Z
// ISO 8601 format (recommended for APIs)
new Date().toISOString()
// "2024-03-15T12:00:00.000Z"Common Edge Cases
- JavaScript Date uses milliseconds, while most other languages and Unix tools use seconds. A common bug is treating a millisecond timestamp as seconds, producing dates in the year 56,000.
- Timestamps are timezone-agnostic but human-readable dates are not. Always store timestamps in UTC and convert to local time only for display.
- The Unix epoch is January 1, 1970, 00:00:00 UTC. Timestamps before this are negative, which can cause issues in systems that use unsigned integers.
- Year 2038 problem: 32-bit signed integer timestamps overflow on January 19, 2038, at 03:14:07 UTC. Use 64-bit integers or switch to ISO 8601 strings before then.
- DST transitions can produce ambiguous local times. The hour from 2:00 to 2:59 AM does not exist on spring forward, and the hour from 1:00 to 1:59 AM occurs twice on fall back.
FAQ
- Should I store timestamps in seconds or milliseconds?
- Use seconds for most cases (Unix standard) unless you need sub-second precision. JavaScript uses milliseconds internally, so conversion is needed at API boundaries. Millisecond precision is required for high-frequency trading, performance monitoring, and event ordering.
- What timezone should I use?
- Always store timestamps in UTC. Convert to local timezone only when displaying to the user. Never store local time without the timezone offset, as this is ambiguous and can lead to data corruption.
- How do I handle leap seconds?
- Unix timestamps do not include leap seconds. The Unix time scale assumes every day has exactly 86,400 seconds, so leap seconds are smearing or handled separately. Most modern systems use the IETF definition where each UTC day has exactly 86,400 SI seconds.