無料のUnix タイムスタンプ変換

What a Unix timestamp is, and why there are two of them

Unix time counts the seconds since 1970-01-01T00:00:00Z — the epoch — and it is deliberately time-zone-free: the same instant has the same timestamp everywhere on the planet. The confusion starts with scale: the classic 10-digit value is Unix seconds, the number you see in command-line tools, log lines, and most APIs. The 13-digit value is Unix milliseconds, the native form of many databases and of JavaScript’s Date — which stores milliseconds since the epoch and is what the platform returns from Date.now(). The converter detects which you pasted from the digit count and renders every other form at once, so a 13-digit log value that looks like a date in the far future is read correctly instead of misparsed as seconds.

Both forms describe the same instant, which is why the tool always shows seconds and milliseconds side by side: mixing them up is one of the most common timestamp bugs in real systems, and the two-column output makes the mismatch visible immediately. If the seconds column and the milliseconds column disagree about what the time is, the input was the wrong one of the two — read the pair, don’t trust one number alone.

Reading log lines and API values

A log line such as 1761330600000 arrives from a service you do not control. Paste it as-is: the converter detects the 13 digits, reads the value as Unix milliseconds, and reports Unix seconds 1761330600, the ISO 8601 string 2025-10-24T19:50:00.000Z, and the same instant in your local time zone. That last rendering is the one that matters when the log came from a server in another region: the instant is the same everywhere, but 19:50 UTC is a different clock time in Tokyo than it is in Paris, and the tool shows both so the value is never misread as local time.

The converter is also the fastest way to sanity-check an API contract. When an endpoint documentation says the field is Unix seconds but the payload shows a 13-digit value, the discrepancy is visible in one paste — the conversion back to seconds shows whether the number plausibly matches the documented era. The tool accepts negative timestamps for pre-1970 dates (the epoch is a reference point, not a lower bound), and it honors the time-zone offset inside an ISO 8601 string, so 2025-10-24T21:50:00+02:00 and 2025-10-24T19:50:00Z convert to the same timestamp.

Going from a date to a timestamp

In the other direction, type or paste a calendar date and the converter returns the Unix seconds and milliseconds for that instant, using your local time zone unless the input itself carries an offset. This is the direction to check before you write code that needs a hard-coded deadline, a scheduled job, or an expiry: the value you compute here is exactly what new Date(...).getTime() ÷ 1000 will produce in the browser, because the tool uses the platform’s own Date and Intl machinery rather than a parallel implementation. That engine-fidelity promise cuts both ways: what you see here is what your runtime computes, including any quirks in how lenient date strings are parsed, so ISO 8601 and numeric inputs are the reliable forms and the tool says so in its limitations.

The limits of the format

A Unix timestamp describes an instant — it says nothing about calendar arithmetic, time-zone abbreviations, or rules like daylight saving. Converting between instants is what the epoch is for; figuring out "9am in the meeting organizer’s time zone" is a different problem, and the converter does not pretend to solve it. Values far outside the platform’s safe range are rejected with a clear error rather than wrapped, and the tool is deliberately local: timestamps from logs and bug reports often sit inside sensitive data, and nothing you paste here is uploaded, logged, or stored.