# agent cron change used utc vs local: fired at the wrong hour

## TL;DR

The cron was written in local time but the platform runs UTC (or vice versa), so it fires hours off. Cloudflare crons are UTC: convert the intended local time to UTC explicitly and document both. Time zones are the eternal cron bug.

```text
agent cron change used utc vs local: fired at the wrong hour
```

## Steps

1. Confirm the offset: the fire time vs intended time differ by the UTC/local delta.
   Expected: The confusion is measured.

2. Rewrite the cron in UTC for the intended local time.
   Expected: The schedule is correct.

3. Document both times in a comment (local intent, UTC expression).
   Expected: The next reader understands.

4. Watch the next two firings to confirm.
   Expected: The fix is proven.

5. Add a schedule sanity check to the deploy pipeline (fire times listed in local).
   Expected: The next confusion is caught.

## When to use

- a cron fires hours off schedule
- the schedule was just changed
- local vs UTC is ambiguous

## When not to use

- the offset is not a whole-hour TZ delta (different problem)
- the platform uses local time (check the docs)
- daylight saving just changed (recompute; UTC does not shift)

## Tool compatibility

- wrangler
- scheduled workers (UTC)

## Variant phrasings

- "cron utc vs local wrong hour"
- "cron fired wrong time timezone"
- "scheduled worker timezone"

## Why it happens

Cron expressions carry no timezone; the platform supplies one (UTC for Workers). A human thinking in local time writes an expression that is correct in the wrong frame. The fix is always the same: decide the local intent, convert to the platform's frame, and write both down.

## Edge cases

- daylight saving moves local times but not UTC expressions; pick which should stay fixed
- the sanity check should print upcoming fire times in local time
- multiple crons need a consistent convention; document it once

## Provenance

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