## TL;DR
Veeam logs write timestamps in formats that vary with locale and product settings, and a parser expecting one format silently drops records it cannot date. Enumerate the actual formats in your logs, parse with explicit format patterns rather than guessing, attach the log timezone deliberately, and make unparseable timestamps raise a visible parsing error instead of a silent skip.

```text
agent cannot parse veeam log timestamps and skipped the failed jobs
```

## Use this when
- Failed jobs near the start or end of log files vanish from agent triage.
- Parsing works on one backup server and fails on another with different locale settings.
- Jobs are triaged to the wrong day, shifting counts between dates.

## Not for this skill when
- Records are assembled wrongly across lines. Record-boundary problem.
- Logs rotate away before triage. Collection problem.

## Steps
1. Sample timestamps from every Veeam log source the agent reads and list their exact formats. Verify: all format variants in production are catalogued
2. Replace generic date parsing with explicit patterns per source plus a strict fallback that errors visibly. Verify: sample records all parse to correct times
3. Set the timezone source of truth per backup server and convert to a single reporting zone. Verify: a job near midnight lands on the correct reporting day
4. Add monitoring for skipped-record counts in the parser output. Verify: any skip above zero alerts
5. Re-run triage for the affected period and reconcile job counts with the console per day. Verify: daily counts match exactly

## Variant phrasings
### veeam log timestamp format parse locale
The format phrasing.
### agent skipped jobs unparseable date silent
The silent-skip variant.
### backup log timezone parsing wrong day
The timezone wording.

Compatibility: Agents parsing Veeam logs from servers with mixed Windows locales and product versions, normalising to UTC or a reporting timezone.

## Why it happens
Timestamp parsing fails quietly in most frameworks: a failed parse becomes a null, a filter drops nulls, and the job disappears without an error anywhere. Locale variation between servers guarantees some records hit the bad path. Explicit formats plus skip accounting turn a silent data loss into an ordinary visible bug.

## Edge cases / pitfalls
- Day and month order ambiguity corrupts silently when both orders parse. Explicit patterns per source are the only defence.
- Preserve the raw timestamp string in parsed records for later disputes.
- Test parsers with logs from every server, not the one nearest the developer.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vPQ0kXiNw3EZ1mqprPLZxw