Log Timestamp Converter

Timestamps buried in server logs, databases and API payloads come in all shapes: Unix epoch seconds like1718000000, milliseconds like 1718000000000, and ISO 8601 strings like2024-06-10T03:33:20Z. This log timestamp converter auto-detects the format by length and shape, then converts it to UTC, KST (Korea time), your browser's local time, plus epoch seconds and milliseconds all at once.

Use it during incident response to line up log times across systems, to turn a KST event time into a UTC epoch, or to quickly read how long ago a log line happened as a relative time. Everything is computed in your browser and nothing is sent to any server.

Auto-detection rules

The input is classified in this priority order.

• 10-digit number: parsed as Unix epoch seconds (e.g. 1718000000).
• 13-digit number: parsed as Unix epoch milliseconds (e.g. 1718000000000).
• Anything else: treated as a date string (ISO 8601 etc.) and parsed with Date.

If you enter digits whose length is not 10 or 13 (say 11–12), it estimates the nearest unit and falls back to seconds when ambiguous. The now button fills in the current time instantly.

Time-zone outputs

• UTC ISO: Coordinated Universal Time like 2024-06-10T03:33:20.000Z — the de-facto standard for stored logs.
• KST: a fixed UTC+9 offset. Korea has no daylight saving, so it is always +9 hours.
• Browser local: rendered in this device's current time-zone setting.

Reading relative time

The reference point is the current moment. Past times show as 3 minutes ago, future ones asin 2 hours. It is handy for sensing whether a log was written just now or days ago. For precise analysis, always cross-check the epoch values. To know when a batch or backup job runs next, pair it with the cron next-run calculator.

Telling the unit from the digit count (reference)

When you can't tell whether a number is seconds or milliseconds, cross-checking the digit count against the resulting year settles it instantly. The same 1718000000 reads as 2024 if you treat it as seconds but as 20 Jan 1970 if you treat it as milliseconds — which is exactly why a wrong unit throws results off by decades.

Rule of thumb: 10 digits is seconds for "this era", 13 digits is milliseconds for the same era. An 11–12 digit number usually means a microsecond (16-digit) or nanosecond (19-digit) value got truncated, or the units are mixed — go back and check the source log format.

Worked example: a KST event time to epoch

Suppose an incident report says "alert fired at 2024-06-10 12:33:20 (KST)". To line it up with other systems you need a UTC epoch. KST is UTC+9, so in UTC that is 2024-06-10T03:33:20Z; feed that into the converter and it returns epoch seconds 1718000000 and milliseconds 1718000000000. Going the other way, if CloudWatch or Kibana emitted 1718000000, drop it in to read KST 12:33:20 and match it against the field report at once.

Common pitfall

• Passing a millisecond value (1718000000000) into seconds-based code like new Date(secs*1000) lands you in the year 54000s. Confirm the unit first.
• An ISO string without a trailing Z or +09:00 is assumed to be local time, so the same input yields different results depending on the viewer's machine time zone.
• When entering a time labeled "KST", always append +09:00. Omit it and the KST digits get misread as UTC, putting you 9 hours off.