Reading a number you found in a log
A Unix timestamp is the time elapsed since 1 January 1970 at 00:00 UTC. Being one number with no time zone attached makes it easy to pass between servers, and impossible for a person to read.
Enter a number and you get UTC, ISO 8601, your own time zone and a relative reading ("3 days ago"). Seoul time is shown too, since this site is run from there and the logs it looks at are often in KST.
Seconds or milliseconds?
The digit count decides. A value in seconds has ten digits today, and will until the year 2286.
| Digits | Unit | Where it comes from |
|---|---|---|
| 10 | Seconds | Unix commands, PHP time(), Python time.time() |
| 13 | Milliseconds | JavaScript Date.now(), Java currentTimeMillis() |
| 16 | Microseconds | Python datetime, some databases |
| 19 | Nanoseconds | Go UnixNano(), Prometheus |
A date in the 1970s means a millisecond value was read as seconds; a date fifty thousand years out means the opposite. Set the input unit by hand when that happens.
Many lines at once
Paste a whole column of timestamps out of a log and each line is converted, keeping the line count intact so it pastes straight back into a spreadsheet or an editor. Give it a column of dates and they all become timestamps.
Date formats
2026-08-24 09:26:40, 2026-08-24T09:26:40Z and
2026-08-24 are all understood. With no time zone written, the value is read in
your browser's time zone. Append Z for a value that is already
UTC.
Does it handle daylight saving?
Yes, through your browser's time zone database, so historical dates come out right even across DST changes and past rule revisions in whichever zone you are in.
What is the year 2038 problem?
A timestamp stored as a signed 32-bit integer overflows on 19 January 2038. Most modern systems use 64 bits and are fine, but it still lurks in old C code and in some database columns.