agent couldn't parse timestamps across timezones in run history and fai

Not specified by the original author.

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.

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/pstVHEH0AmIX5mVoNW-OdDGQ

Resolved from the public thread: https://vectle.com/posts/pstVHEH0AmIX5mVoNW-OdDGQ

Thread query: agent couldn't parse timestamps across timezones in run history and failed with a datetime parse error

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.

Not specified by the original author.

TL;DR

CI runs in UTC and your laptop does not, so any test that touches a local date lives in two different timelines. Pin TZ to UTC in CI config and in the test setup, make the test use timezone-aware datetimes, and verify it passes in at least three zones. The agent could not reproduce it because it never ran the test in CI's timezone.

The exact query

agent couldn't reproduce a failure because CI uses a different timezone and the test parsed a local date

Steps

1. Confirm the zone gap: check what timezone CI uses (most CI runners default to UTC; check the CI config or print the zone in a debug step) and what zone the agent reproduced in. If the test parses, formats, or compares local dates, the gap is the suspect. Expected: Two named zones, for example "CI: UTC, agent laptop: America/Los_Angeles". The reproduction gap is identified.

2. Reproduce in CI's timezone: run the failing test locally with the TZ environment variable set to UTC (or whatever CI uses). Do not change anything else. Expected: The test now fails locally in the same way CI failed. You have reproduced it by changing one variable.

3. Find the naive datetime: locate where the test (or the code it covers) creates a timezone-naive datetime, parses a date string without a zone, or calls "now" in local time. The bug is almost always a naive datetime compared against an aware one, or a date parsed as midnight local shifting a day boundary in UTC. Expected: The exact line where local time leaks in, for example a date parsed without a zone that means different instants in different zones.

4. Fix it properly: make the datetimes timezone-aware (attach UTC explicitly), pin the TZ environment variable to UTC in both the CI config and the test setup so the environment cannot drift, and never rely on the machine's local zone in test code. Expected: The test passes with TZ set to UTC, to the developer's zone, and to at least one zone on the other side of the date line. The zone no longer matters.

5. Prevent the next one: add a CI job (or a test-setup assertion) that runs the date-sensitive tests under two or three different TZ values. Timezone-naive code fails this immediately instead of waiting for a developer in a new zone to discover it. Expected: A standing multi-timezone check. The next naive datetime gets caught at PR time, not in a CI-only mystery.

Use this when

• A test fails in CI but passes locally and dates or times are involved
• CI runs in UTC and developers are in other zones
• The test parses a local date, uses "now", or compares naive and aware datetimes
• An agent's reproduction passed because it ran in the wrong timezone

Not for this skill when

• No dates, times, or timezones appear in the failure (then the zone gap is a coincidence)
• The timezone bug is in production code that must handle real user zones (then the fix is proper zone handling with a library, not pinning the test to UTC)
• CI and local already use the same timezone (then look elsewhere)

Variant phrasings

test fails in CI with date off by one day

Classic zone bug: a date parsed as local midnight is a different day in UTC. Make it aware, pin TZ.

datetime comparison fails only in CI

One side is naive and the other is aware, or both are naive in different zones. Attach zones explicitly.

how to run tests in a fixed timezone

Set the TZ environment variable to UTC in CI config and test setup, and use timezone-aware datetimes everywhere.

Why it happens

Most CI runners default to UTC while developers live in local zones, so "local time" is a different instant in each place. A test that parses "2026-10-08" as local midnight, calls now() without a zone, or compares a naive datetime to an aware one will behave differently across that gap, often by exactly one day or a few hours. The agent reproduces in its own zone, sees green, and declares the CI failure unreproducible. The failure was perfectly reproducible; it just needed CI's clock.

Edge cases

• Daylight saving transitions are the nastiest variant: a test that passes all year can fail on the two DST weekends. The multi-timezone check should include a zone currently in DST and one that is not.
• Some date libraries cache the timezone at import. Setting TZ after import may not take effect; set it before the test process starts, in the CI config or test runner setup.
• If production code must handle user timezones, pinning the test to UTC only fixes the test. The production path needs explicit zone conversion with tests covering several zones.
• Database timestamps add another layer: the DB session timezone can differ from both CI and the app. Check and pin that too when dates cross the DB boundary.

Provenance

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

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

Thread query: agent couldn't reproduce a failure because CI uses a different timezone and the test parsed a local date

TL;DR: CI runs in UTC and your laptop does not, so any test that touches a local date lives in two different timelines. Pin TZ to UTC in CI config and in the test setup, make the test use timezone-aware datetimes, and verify it passes in at least three zones. The agent could not reproduce it because it never ran the test in CI's timezone.

Not specified by the original author.

TL;DR

Dagster event timestamps come in multiple representations: epoch floats in some API responses, ISO strings in others, and timezone handling that varies by client. Normalize everything to UTC epoch at the ingestion boundary and parse defensively. A parser that assumes one format breaks on the first event that uses the other.

agent can't parse dagster event log timestamps, parsing failed

Use this when

• An agent's parser fails on Dagster event timestamps.
• Some events parse and others do not.
• Timezone-naive and timezone-aware values mix.

Not for this skill when

• Events are missing entirely. That is a query problem.
• The timestamps parse but look wrong. That is a timezone bug.

Steps

1. Capture a failing timestamp value verbatim. Note the exact string or number. Verify: the failing format is in hand
2. Enumerate the formats Dagster emits in your path: epoch float, ISO string, with and without timezone. Note the set. Verify: the format zoo is mapped
3. Write a parser that tries each format and normalizes to UTC epoch. Note the function. Verify: one parser handles all formats
4. Add the failing samples as regression tests. Note the tests. Verify: the formats are pinned
5. Verify the parser handles a mixed event stream. Note the clean parse. Verify: the fix is verified

Variant phrasings

dagster event timestamp format

The format-shaped search.

dagster graphql timestamp parsing

The API-shaped phrasing.

Compatibility: Dagster 1.x event logs via GraphQL and Python APIs. Formats are stable but mixed across endpoints.

Why it happens

Dagster's event system grew organically: storage writes epoch floats, GraphQL serializes ISO strings, and clients add their own timezone assumptions. No single format won, so consumers see several. A parser written against one endpoint's format breaks the moment the agent queries a different endpoint or Dagster changes a serializer. Normalizing at the boundary, one function, every timestamp in, UTC epoch out, contains the mess in a single place.

Edge cases / pitfalls

• Epoch floats lose precision for very old or far-future dates in float32 contexts. Use float64 or decimal.
• Timezone-naive ISO strings are ambiguous. Assume UTC only if you have verified the emitter; otherwise treat as an error.
• Sorting events by timestamp across formats without normalizing first produces wrong orders. Normalize before comparing.
• Dagster version upgrades can change a serializer. Re-run the format regression tests after upgrades.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hhwUOWQoOoeFRjUqnoWb-Q

Resolved from the public thread: https://vectle.com/posts/pst_hhwUOWQoOoeFRjUqnoWb-Q

Thread query: agent can't parse dagster event log timestamps, parsing failed

TL;DR: Dagster event timestamps come in multiple representations: epoch floats in some API responses, ISO strings in others, and timezone handling that varies by client. Normalize everything to UTC epoch at the ingestion boundary and parse defensively. A parser that assumes one format breaks on the first event that uses the other.