infoOverview

An API response or a log line full of raw epoch seconds (or milliseconds) is unreadable at a glance, and doing the conversion by hand — including the timezone math — is a common source of off-by-some-hours mistakes. This tool converts UNIX timestamps to and from human-readable date/time in both directions, handling both second and millisecond precision, multiple output formats (ISO 8601, RFC 2822), and any IANA timezone including daylight saving time transitions.

checklistHow to Use

1. 1Pick To Date/Time or To UNIX Timestamp from the Conversion Mode selector, depending on which direction you're converting.
2. 2Converting a timestamp to a date: Paste the value into the UNIX Timestamp field — seconds or milliseconds are both accepted.
3. 3Converting a date to a timestamp: Fill in Date, Hours, Minutes, and Seconds for the moment you want encoded.
4. 4Set Timezone to an IANA identifier (e.g., Asia/Tokyo) so the conversion lands in the right local time, DST included.
5. 5Click Convert and read the result from the Conversion Result card.

menu_bookSpecifications & Glossary

• UNIX timestamp (epoch time): A signed count of seconds since the UNIX epoch, January 1, 1970 00:00:00 UTC. Systems that still store this count in a 32-bit signed integer run out of room on January 19, 2038 at 03:14:07 UTC — the well-known "Year 2038 problem," the practical successor to Y2K for anything still running 32-bit time_t.
• Second timestamp: A 10-digit number — the classic UNIX timestamp, equivalent to Math.floor(Date.now() / 1000) in JavaScript. This is the format most UNIX/Linux tools and many backend frameworks (PHP's time(), Python's time.time()) use by default.
• Millisecond timestamp: A 13-digit number — what you get from JavaScript's Date.now() or Java's System.currentTimeMillis(). If a value you're inspecting has 13 digits instead of 10, it's almost certainly milliseconds, not seconds; feeding it into a seconds-based parser unmodified is a common bug.
• ISO 8601: The standard format you'll see in JSON APIs and most modern logging, e.g. 2024-01-15T12:30:00+09:00. The explicit offset removes the ambiguity that comes from logging a bare local time without saying which timezone it's in.
• RFC 2822: The format used in email Date: headers and some legacy HTTP contexts, e.g. Mon, 15 Jan 2024 12:30:00 +0900. Less common in new APIs than ISO 8601, but still worth recognizing when you're parsing email metadata or older system logs.
• IANA timezone database: The Timezone field uses identifiers from the IANA Time Zone Database (tz database) — region/city names like Asia/Tokyo or America/New_York rather than fixed UTC offsets. That's deliberate: a fixed offset like UTC-5 silently breaks across a daylight saving time transition, while a named zone like America/New_York adjusts automatically.

lightbulbUse Cases

• Translating raw epoch values in a JSON API response into a date you can actually read while debugging.
• Decoding epoch timestamps in server or application log files when correlating events across services.
• Comparing event times reported in different timezones, e.g. confirming what a UTC server timestamp corresponds to in a user's local time.
• Checking whether a future date falls past the Year 2038 problem boundary (January 19, 2038, 03:14:07 UTC), where a system still using a signed 32-bit integer for time_t wraps around to a negative number. This is a real, recurring issue in older embedded systems, some database column types, and legacy code that hasn't migrated to 64-bit timestamps — convert a target date here to confirm it's outside (or inside) the danger zone before scheduling something far in the future.