## TL;DR
Airflow logs timestamps in the timezone of the Airflow configuration, which is UTC by default even when your team thinks in local time, and log lines carry that zone in their format. An agent that parses them as naive local time shifts every event by the local offset, and a daylight saving change can make durations between two log lines wrong by an hour even when both were shifted. Parse with the zone the log actually declares, convert to one reference zone, and validate against the task instance start and end times from the metadata, which Airflow stores in UTC.

```text
agent parsed airflow task log timestamps in the wrong timezone, duration wrong
```

## Use this when
- Durations an agent computed from task logs disagree with the durations shown in the Airflow UI.
- Parsed event times are off from known wall clock events by a fixed number of hours.
- Errors appear or vanish around a daylight saving change date.

## Not for this skill when
- The task itself ran long and the UI agrees. That is a slow task, not a parsing problem.
- Log lines come from user code printing its own naive timestamps in arbitrary formats. Those need per source handling.

## Steps
1. Take one task instance and record three versions of its start: the Airflow UI value, the metadata value through the API or CLI, and the agent's parsed value from the log. Note the differences in hours. Verify: the shift is measured against Airflow's own record
2. Read the raw log header lines and identify the timestamp format and any zone marker Airflow wrote, plus the default timezone in the Airflow configuration. Note the declared zone. Verify: the log's own timezone is established from the file, not assumed
3. Fix the parser to read the timestamp with that zone explicitly, converting to UTC for storage and comparison, and never to attach the machine's local zone to a zone-less parse. Note the parser change and its format string. Verify: parsing is pinned to the log's declared zone
4. Recompute durations for the sample task and for a task that ran across a daylight saving boundary if one exists, and compare both with the UI durations. Note both match. Verify: the fix is checked on the hardest case, the clock change
5. Apply the corrected parser to the timeline or reporting job and restate any reports the bad parse produced for the affected period. Note the reports corrected and the period covered. Verify: downstream consumers stop using shifted times

## Variant phrasings
### airflow log timestamps timezone UTC parse duration mismatch
The format and zone phrasing.
### airflow task duration from logs off by hours daylight saving
The clock change symptom version.

Compatibility: Airflow 2.x and 3.x task logs with the standard logging format, and metadata task instance timestamps stored in UTC. Remote log storage in object storage does not change the timestamp semantics.

## Why it happens
Timestamps in logs are text, and text has no timezone until a parser assigns one. Three different defaults collide here: Airflow's configured timezone, usually UTC by deliberate default; the log format, which may print an offset or an abbreviation that parsers handle inconsistently; and the agent environment's local zone, which a naive parse silently adopts. Each event still looks like a reasonable time, so nothing errors. Only arithmetic exposes it, durations that stretch or shrink by the offset, and events that appear to happen before the task that produced them.

## Edge cases / pitfalls
- Abbreviated zone markers are ambiguous across regions. Prefer the numeric offset in the log line when one is present.
- Log lines from libraries inside the task may use their own format and zone. Segment the parse by line source instead of one format for the whole file.
- A task retried across a clock change can have log segments in different local renderings if workers differ. Normalise per segment using each segment's declared marker.
- Store parsed times with their zone or as UTC instants. Storing a corrected wall clock without the zone recreates the bug for the next consumer.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_B-GBLo03micFCBtviiefhQ