Unix Timestamp Converter

Seconds or Milliseconds? — The Most Common Mistake

The same moment in time can be represented as `1700000000` or `1700000000000`. Unix-like systems, Python, PHP, and MySQL use seconds, while JavaScript and Java use milliseconds. Every time you cross this boundary, off-by-1000 errors happen.

The symptoms are always the same. If you provide a seconds-based value where milliseconds are expected, you'll get a date somewhere in mid-January 1970. If you do the reverse, you'll end up with a date tens of thousands of years in the future. If your date is stuck in 1970 or is ridiculously far off, this is the first thing you should suspect.

• JavaScript: `Date.now()` is in milliseconds. If an API expects seconds, use `Math.floor(Date.now() / 1000)`.
• PHP: `time()` is in seconds. `microtime(true)` returns seconds with a decimal part.
• MySQL: `UNIX_TIMESTAMP()` returns seconds. `FROM_UNIXTIME()` also expects seconds.
• Python: `time.time()` returns seconds with a decimal part. Use `int()` to truncate it.

UTC vs. KST (+9) — Where 9 Hours Appear or Disappear

A timestamp itself has no time zone. The value `1700000000` represents the same instant everywhere in the world. It just looks different depending on where you are: 7:13 AM in Seoul, but 10:13 PM the previous night in London. That's why a phrase like 'convert the timestamp to KST and save it' doesn't make sense. The moment you add or subtract nine hours, it becomes an incorrect timestamp pointing to a different moment in time.

For services operating in Korea, the 9-hour offset problem usually appears in a few common places.

• The database server's time zone is UTC, but the application interprets it as KST. This causes query results to be off by nine hours. You need to check MySQL's `time_zone` setting and the connection options together.
• Mixing `DATETIME` and `TIMESTAMP` types. In MySQL, `TIMESTAMP` is converted to and from UTC during storage and retrieval, but `DATETIME` is not. Comparing these two column types will lead to discrepancies.
• The definition of 'today'. If you run daily statistical aggregations based on UTC midnight, the 'day' will roll over at 9 AM in Korea. For local services, daily metrics should be aggregated based on KST midnight to align with business expectations.
• Omitting the 'Z' from an ISO string. `2026-07-16T09:00:00Z` and `2026-07-16T09:00:00+09:00` are nine hours apart. A string without the `Z` (for UTC) or an offset will be interpreted based on the parser's own context, which is often its local time zone.

The Year 2038 Problem — It's Still Alive

When you count seconds using a 32-bit signed integer, it will overflow on January 19, 2038, at 03:14:07 UTC (12:14:07 PM KST). One second later, the time wraps around to the year 1901. It may seem like a forgotten issue now that 64-bit systems are common, but you can still run into it.

• MySQL's `TIMESTAMP` column can only store dates up to 2038-01-19. For dates beyond that, you must use `DATETIME`. Services that handle data like 30-year loan maturities or long-term contract expiration dates are hitting this wall today.
• 32-bit embedded devices, old routers, and POS terminals will malfunction if their firmware isn't updated.
• This tool uses JavaScript's `Date` object, so it handles dates beyond 2038 without any issues. Just because a date looks correct here doesn't mean the target system can handle it.

ISO 8601 vs. RFC 2822 — Which to Use Where

The results table shows multiple formats because different systems require different formats.

Common Mistakes with Relative Time

The 'Relative time' at the top of the table shows how long ago or how far in the future a date is. It's a common format for forums and notification lists, but it's surprisingly easy to get wrong when you implement it yourself.

• Approximating a month as 30 days. Most libraries, including this tool, do this. This means '1 month ago' could actually be 28 days ago or 31 days ago. For screens where precision matters (like contracts or billing), show the actual date instead of a relative time.
• Clock skew between server and browser. If a user's PC clock is five minutes fast, a post they just wrote might appear as 'in 5 minutes'. You should add logic to handle future dates, for instance, by displaying them as 'just now'.
• Caching. If '3 minutes ago' is baked into the HTML and cached by a CDN, it will still say '3 minutes ago' long after. It's safer to calculate relative time on the client side.