단위 변환기

Why computers count seconds from 1970

A Unix timestamp is a single number: the count of seconds that have elapsed since midnight UTC on 1 January 1970, a moment engineers call the epoch. Storing time as one integer is enormously convenient. There is no timezone, no daylight-saving ambiguity, no locale-specific month names — just a number that always increases. Two servers on opposite sides of the planet agree on the exact same timestamp for the same instant, then each translates it into local wall-clock time only when a human needs to read it. That is why timestamps appear everywhere in logs, APIs, databases, and file metadata, and why being able to convert them quickly is a daily need for developers.

Seconds, milliseconds, microseconds — and how this tool tells them apart

The same instant can be written at different resolutions, and the only difference is how many digits the number has. This converter detects the unit automatically from the length of what you paste:

The detection rule is purely by digit count: 16 or more digits are read as microseconds, 13 or more as milliseconds, otherwise seconds. A small hint under the input box tells you which unit was assumed, so if your value lands at a boundary you can confirm the tool guessed correctly.

A worked example

Paste 1700000000 into the timestamp field. It has ten digits, so it is read as seconds. Internally the tool multiplies by 1000 to make a JavaScript date and produces three readings of the same instant: your local time (formatted for your computer's region), the UTC string (Tue, 14 Nov 2023 22:13:20 GMT), and the ISO 8601 form 2023-11-14T22:13:20.000Z. Going the other way, pick a date in the right-hand panel and the tool returns the same moment as a seconds value, a milliseconds value (seconds × 1000), and a microseconds value (× 1,000,000), plus a friendly "relative" label such as "2 years ago".

The Year 2038 problem

Older systems store the timestamp in a signed 32-bit integer, which can only count up to 2,147,483,647. That ceiling is reached at 03:14:07 UTC on 19 January 2038. One second later, the counter overflows into a negative number and the date wraps back to 1901 — the time bug equivalent of an odometer rolling over. Modern platforms use 64-bit integers, which push the overflow hundreds of billions of years into the future, but legacy embedded devices and old file formats are still at risk. If you ever see a timestamp that decodes to a 1901 date, an overflow is the likely cause.

Practical use cases

• Debugging API responses. Most JSON APIs return timestamps as raw numbers. Paste one here to instantly see when an event actually happened.
• Reading log files. Server and application logs frequently prefix lines with epoch seconds; converting them shows the true sequence of events.
• Setting expiry values. JWTs and cache headers use Unix seconds. Enter a future date to get the exact integer to put in an exp claim.
• Cross-checking timezone handling. Compare the local and UTC outputs to confirm your code is converting correctly.

Common mistakes

• Mixing up seconds and milliseconds. Feeding a milliseconds value into a function that expects seconds throws the date roughly 50,000 years into the future. The auto-detected unit hint helps you catch this before you copy.
• Assuming the epoch is local. The epoch is defined in UTC. A timestamp is timezone-neutral; only the displayed wall-clock time depends on a zone.
• Forgetting leap seconds. Unix time deliberately ignores leap seconds, so it is not a perfectly continuous count of physical seconds. For everyday work this never matters, but it explains rare one-second discrepancies in scientific contexts.

How to read the result, and privacy

To grab the current epoch, click Now; it fills the field with Math.floor(Date.now() / 1000), the same expression you would use in code. Every conversion happens locally with your browser's own date engine — nothing you enter is transmitted to a server, so timestamps from private logs stay on your machine.