Log Timestamp Parser
Timestamp
2026-03-26 14:30:45
Level
ERROR
How it works
Server and application logs embed timestamps in dozens of inconsistent formats — ISO 8601, syslog format, Apache Combined Log Format, Nginx default, Windows Event Log, Unix epoch, and custom strftime patterns. Parsing these timestamps is the first step in log analysis, enabling chronological sorting, time-range filtering, and duration calculations.
**Common log timestamp formats** ISO 8601: 2024-03-15T14:23:45.123Z or 2024-03-15T14:23:45+05:30. Apache/Nginx CLF: [15/Mar/2024:14:23:45 +0000]. Syslog (RFC 3164): Mar 15 14:23:45. Syslog (RFC 5424): 2024-03-15T14:23:45.123456+00:00. Windows Event Log: 3/15/2024 2:23:45 PM. Unix epoch: 1710512625 (seconds) or 1710512625123 (milliseconds — 13 digits).
**Timezone handling** Logs without timezone information are ambiguous. Syslog RFC 3164 omits timezone — assume local server time or UTC depending on server configuration. ISO 8601 with Z suffix is always UTC. Daylight saving time transitions create duplicate timestamps during fall-back (01:30 occurs twice). For distributed systems, all components should log in UTC; convert to local time only for display.
**Parsing in practice** Python dateutil.parser.parse() handles most formats automatically. For performance-critical parsing of millions of log lines, use pre-compiled strptime patterns. GNU awk and sed can extract and normalize timestamps in shell pipelines. This tool accepts pasted log lines and extracts, normalizes, and displays all detected timestamps in ISO 8601 UTC.
Frequently Asked Questions
- Best practice: standardize all logs to UTC at the source — configure applications to log in UTC and use log aggregation systems (Elasticsearch, Datadog, Splunk) that normalize all ingested timestamps to UTC. Convert to local time only for display. When logs mix time zones, use a log processor (Logstash grok patterns, Fluentd parsers) to detect and normalize each format. For post-hoc analysis of mixed-timezone logs, extract the timezone offset alongside the timestamp and convert explicitly.
- Unix epoch is the number of seconds (or milliseconds) since 1970-01-01T00:00:00Z. Seconds: a 10-digit number (1710512625 = 2024-03-15T14:23:45Z). Milliseconds: a 13-digit number (1710512625000). Convert in Python: datetime.fromtimestamp(1710512625, tz=timezone.utc). In JavaScript: new Date(1710512625000).toISOString(). In shell: date -d @1710512625 (GNU date). Millisecond vs second confusion is a common bug — dividing by 1000 or multiplying by 1000 as needed.
- ISO 8601 defines a standard date/time format: YYYY-MM-DDTHH:MM:SS.sss±HH:MM. Example: 2024-03-15T14:23:45.123+05:30 or 2024-03-15T14:23:45.123Z (UTC). Advantages: lexicographically sortable (sort alphabetically = sort chronologically), unambiguous (no 01/02/2024 day-month-month ambiguity), internationally recognized, machine-parseable by virtually all languages. Use ISO 8601 in UTC (the Z suffix) for all new logging — it is sortable, unambiguous, and requires no time zone lookup to parse.
- DST transitions create two problems: spring forward (one hour of timestamps is skipped — no logs exist for those 60 minutes in local time), and fall back (one hour of timestamps is duplicated — two different hours with identical local timestamps). UTC avoids both problems — UTC has no DST transitions. For logs already in local time, the fall-back duplicate-hour problem requires context from the DST transition schedule to disambiguate. Elasticsearch and most log management systems handle this correctly when timestamps include timezone offset.