Parsing Every Log Format: The Timestamp Problem in LogSleuth

Every application writes logs differently. IIS uses W3C format. Veeam has its own structured layout. SQL Server writes errors with a specific date prefix. Syslog comes in two incompatible standards and most implementations violate at least one of them.

If you want a single tool that loads any of these and lets you search and correlate across them, you have to solve three problems: detecting the format, parsing timestamps that conform to no single standard, and correlating events across files that disagree about what time it is.

LogSleuth does this. The solutions are less elegant than I’d like and more effective than I expected.

Auto-detection

When you open a file, LogSleuth scores it against each built-in profile (Veeam, IIS, SQL Server, Exchange, syslog, and others). Scoring has two components: regex patterns characteristic of the format matched against a sample of lines, plus a filename bonus if the name matches what that application typically produces.

If nothing matches well, it falls back to plain text — severity assigned by keywords (ERROR, WARN, INFO in the line), timestamp attempted with the heuristic chain below. Imprecise, but searchable. Manual override is always available.

The timestamp problem

This is where the interesting part is.

Timestamps in log files are a disaster. Different formats, different precisions, timezone offsets sometimes included and sometimes not, ambiguous date ordering, and some applications omit the year entirely because they assume you’re reading the log in the same year it was written.

LogSleuth uses a 15-heuristic fallback chain. When the profile’s primary pattern doesn’t match, each is tried in order:

1. RFC 3339 / ISO 8601 — 2026-05-01T14:32:11Z and variations
2. Log4j — 2026-05-01 14:32:11,123
3. ISO with space — 2026-05-01 14:32:11
4. ISO date only — 2026-05-01
5. Unix epoch (seconds) — bare integer
6. Unix epoch (milliseconds) — integer × 1000
7. BSD syslog — May 1 14:32:11 (no year — injects current year)
8. US date — 05/01/2026 14:32:11
9. European date — 01/05/2026 14:32:11
10. Short month name — 01 Mar 2026 14:32:11
11. Long month name — 01 March 2026 14:32:11
12. Windows event-style — 5/1/2026 2:32:11 PM
13. Compact date — 20260501
14. Veeam-specific — [01.05.2026 14:32:11]
15. Fallback — no timestamp, sorted to end

The BSD syslog case (7) injects the current year because the format doesn’t include one. This is correct for logs from this year and wrong for archived logs. There’s no good answer — if the log doesn’t say, you guess. Current year is the least-wrong guess.

The US/European ambiguity (8 and 9) is handled by profile where possible: IIS uses US, most European system logs use European. When the profile doesn’t specify, both are tried and the result that looks plausible wins (not in the future by more than a year, not before 2000).

Time correlation

The most useful feature when something’s gone wrong across multiple systems: click an error in one log, see what was happening in all the others within ±30 seconds of that timestamp.

LogSleuth highlights entries within a configurable window of a selected entry across all loaded files. Click an error in the Veeam log at 14:32:11 and the SQL Server log, agent log, and Windows event log light up around the same time. You see the cascade immediately.

This breaks when sources are on machines with unsynchronised clocks, or when one uses UTC and another uses local time. The correlation window exists partly to absorb minor clock drift. For genuinely out-of-sync clocks, you can widen the window in settings.

LogSleuth is on GitHub, MIT licensed.