Log Timestamp Converter
Read any log timestamp and convert it across formats and zones.
What you provide
Any IANA timezone name, such as UTC, Europe/London or America/New_York.
How this calculation works
The format is detected from the shape of what you paste. Epoch seconds, milliseconds and microseconds are told apart by magnitude, which is unambiguous for any date this century. Syslog and common log format are matched by pattern, and anything else falls back to standard date parsing. Where a format leaves something out, such as syslog omitting both the year and the timezone, the assumption made is reported alongside the answer rather than quietly applied.
What the results mean
- Detected format
- What the input was recognised as. Worth a glance, since a value that could be either seconds or milliseconds resolves to dates decades apart.
- ISO 8601 (UTC)
- The unambiguous form. When correlating events across systems, convert everything to this before comparing anything.
- Assumptions
- Shown when the format omitted information. Syslog has no year and no offset, so both are inferred, and both are wrong under predictable circumstances.
Common problems and fixes
- The date comes out around 1970 or far in the future
- The units are being read differently than intended. Ten digits is seconds, thirteen is milliseconds, and sixteen is microseconds. If a value has an unusual length, check whether it is a different epoch entirely, since Windows file times and some databases count from other origins.
- Events from two servers do not line up
- Convert both to UTC before comparing, since one may be logging local time without an offset. Then check for clock drift, because a few seconds of skew between machines is enough to put an effect before its cause in a merged timeline. Confirm both are synchronised, and prefer log formats that carry an explicit offset.
Frequently asked questions
Why does syslog omit the year?
The format dates from a time when logs were read locally and rotated frequently, so the year was assumed to be obvious. It is a genuine problem when reading archived logs, and it is the reason the newer RFC 5424 format uses full ISO 8601 timestamps instead.
Should servers log in UTC or local time?
UTC, with an explicit offset in the format. Local time introduces an hour that repeats and an hour that never happens each year in any region observing daylight saving, and sorting a log across that boundary produces an order that is simply wrong. UTC has neither problem.
What is the year 2038 problem?
A signed 32-bit counter of seconds since 1970 overflows in January 2038. Modern systems use 64-bit values and are unaffected, but embedded devices and old file formats can still carry 32-bit timestamps, and they typically wrap to 1901 rather than failing visibly.
Put this on your own site
Free to embed, no attribution required beyond the source link the frame carries itself. It runs entirely in your visitor's browser, sets no cookies and loads no third-party script.
<iframe src="https://runthetests.com/embed/log-timestamp-converter/" width="100%" height="560" style="border:1px solid #e5e5e5;border-radius:8px" title="Log Timestamp Converter" loading="lazy"></iframe>
Preview it at https://runthetests.com/embed/log-timestamp-converter/. Embedded pages are marked noindex, so yours stays the canonical copy — not this one.