## TL;DR
Normalise every timestamp to UTC at parse time and refuse naive datetimes: run histories mix timezone-aware and naive stamps from different tools, and comparing or sorting them directly throws or, worse, silently misorders. Detect each source's format and offset, convert on ingestion, and store the original string alongside so conversions can be audited.

```text
agent couldn't parse timestamps across timezones in run history and failed with a datetime parse error
```

## Use this when
- The run or call fails with this symptom: agent could not parse timestamps across timezones in run history and failed with a datetime parse error.
- You are working on an agent processing run histories exported from several trackers and the failure repeats on the same run or configuration.
- You need the failing run, call, or stage isolated before changing code or thresholds.

## Not for this skill when
- A source whose timestamps are actually local times mislabelled as UTC, where the fix is correcting that source's offset at ingestion.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Sample timestamps from each source and catalogue their formats: offsets present, Z suffixes, or naive strings. Verify: every source's format is documented
2. Write per-source parsers that produce timezone-aware UTC values, assigning a stated default zone only where a source is known naive. Verify: all parsed stamps are aware and comparable
3. Convert the failing history end to end and check ordering against the tracker's own run order. Verify: the parsed order matches the source order
4. Keep the raw string with each parsed value and flag any stamp that needed the default-zone assumption. Verify: assumptions are visible in the data

## Variant phrasings
### agent parse timestamps timezones run history datetime error
The verbatim phrasing.
### run history mixed timezone naive aware agent fix utc
The normalisation phrasing.
### agent datetime parse failed tracker exports offsets
The offsets phrasing.

Compatibility: Agent parsers reading run history timestamps across timezones

## Why it happens
Datetime libraries refuse to compare aware and naive values for good reason, and multi-tool histories guarantee both kinds. The parse error is the safe outcome; the dangerous one is a parser that guesses zones per value and quietly scrambles chronology.

## Edge cases / pitfalls
- Daylight-saving transitions make one local hour ambiguous; a stated default zone should also state its DST assumption.
- Epoch timestamps from some tools are milliseconds, not seconds; a factor-of-1000 check belongs in the catalogue step.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VHEH0AmIX5mVoNW-O_dDGQ