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.

API responses and log files usually emit raw Unix timestamps as-is, so instead of reaching for a calculator or writing a one-off script, you can just paste the value in and get a readable date instantly. It also works the other way — enter a specific date and time to get the corresponding timestamp for a database query or test fixture.

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.

Note: a 10-digit input is automatically interpreted as seconds and a 13-digit input as milliseconds. If the digit count doesn't match what you expect, the result will land on a wildly wrong date — double-check the number of digits first.

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.
• Negative timestamps: dates before January 1, 1970 are represented as negative numbers. Most languages and libraries support negative values, but some older systems don't, so check the target system's behavior if you're passing the value along.

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.
• Eyeballing the value of a Unix timestamp column returned from a database query without writing a conversion function.

quizFAQ

How does the tool know if my timestamp is in seconds or milliseconds?

It's inferred from the number of digits. Roughly 10 digits (covering dates from 2001 to around 2286) is treated as seconds, and 13 digits (covering 1970 through well past 2001) as milliseconds. An unexpected digit count will produce a wildly wrong date, so check the digit count if the result looks off.

What changes when I switch the time zone?

The underlying Unix timestamp is always a UTC-based absolute value and doesn't change when you switch time zones. Only the displayed year/month/day/hour/minute/second changes, converted to local time for the selected IANA zone with daylight saving time (DST) applied automatically.

What is the Year 2038 problem?

Older systems that store Unix time as a signed 32-bit integer will overflow at 03:14:07 UTC on January 19, 2038, causing dates to be handled incorrectly after that point. Modern 64-bit systems and JavaScript's number type are unaffected, but embedded devices and legacy C programs can still be at risk.

Can this handle dates before 1970 or negative values?

Yes. Dates before January 1, 1970 are represented as negative timestamps, and this tool converts them correctly. Some external systems or libraries don't support negative values though, so check the spec of whatever you're integrating with.

Are leap seconds taken into account?

No. By definition, Unix time ignores leap seconds and treats every day as exactly 86400 seconds. This matches the common POSIX-standard implementation, and this tool follows the same convention.

Can I quickly get the current timestamp?

Leave the date field at its default in "Convert to date" mode, or use the current time as the starting value, to see the current moment expressed as both a seconds and a milliseconds Unix timestamp.