Log Timestamp Parser

A Unix epoch timestamp is the number of milliseconds (or seconds) that have elapsed since January 1, 1970 at 00:00:00 UTC. Log systems like LogScale, New Relic, and VMware Aria store timestamps internally in this format because it is timezone-agnostic, easy to sort numerically, and requires no locale parsing. For example, 1542400149000 ms equals 11/16/2018 @ 8:29pm UTC.

The parser supports ISO 8601 (e.g. 2024-03-15T14:23:45.000Z), Unix epoch in both milliseconds and seconds, Syslog (Mar 15 14:23:45), Apache CLF (15/Mar/2024:14:23:45 +0000), SQL/Log4j (2024-03-15 14:23:45), US 12-hour format (03/15/2024 @ 2:23pm (UTC)), slash-separated datetime (2024/03/15 14:23:45), and full human-readable format (March 15 2024 14:23:45).

ISO 8601 is an international standard for representing dates and times, written as yyyy-MM-ddTHH:mm:ss.SSSZ — for example 2024-03-15T14:23:45.000Z. It is unambiguous across locales and timezones, sorts correctly as a string, and is widely supported by log management platforms including New Relic, Oracle Log Analytics, and LogScale. Most modern log forwarders emit ISO 8601 by default.

If your timestamp string already contains timezone information — such as a Z suffix (UTC), a +0000 offset in Apache CLF, or a named zone like (UTC) — the parser uses that information directly and ignores the timezone offset field. Only set the source timezone offset manually when your log timestamps have no timezone indicator, for example plain syslog entries that are written in local server time.

@timestamp represents the time the original event occurred, extracted from the log content by the parser. @ingesttimestamp is the time the log line was received and processed by the platform. Because of network latency and log shipping delays, there is typically a small difference between the two. Always configure your parser to extract @timestamp correctly so your log searches reflect actual event times rather than ingestion times.

Ambiguous timestamps can confuse auto-detection — for example, 01/02/2024 could be January 2nd (US) or February 1st (European). If you see an unexpected result, select the specific source format manually from the dropdown. Timestamps without any timezone suffix are also assumed UTC unless you set a source timezone offset.

Yes — simply copy just the timestamp portion from your log line and paste it into the Raw Timestamp String field. This parser focuses on the timestamp value itself rather than the surrounding log text, so you don't need to paste the entire log entry. For full log parsing with field extraction, you would use a dedicated log management platform with Grok or regex-based parsers.

Common specifiers include: %Y or yyyy for 4-digit year, %m or MM for zero-padded month, %d or dd for zero-padded day, %H or HH for 24-hour hour, %M or mm for minutes, %S or ss for seconds, %f or SSS for milliseconds, %z or Z for UTC offset, %b or MMM for abbreviated month name, and %A for full weekday name. These follow strftime conventions (used by Python/C log parsers) or Java SimpleDateFormat conventions (used by Logstash, LogScale, Log4j).