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.

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.

1. 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.

1. 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.

1. 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.

1. 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