fix(cron): repair migrated timezone offsets by ScubaSteeve · Pull Request #28985 · NousResearch/hermes-agent

ScubaSteeve · 2026-05-19T23:55:09Z

Summary

Detect persisted cron next_run_at values that still use an old UTC offset after Hermes timezone migration
Rebase those timestamps to the current Hermes timezone while preserving the intended cron wall-clock time
Keep stale-run fast-forward behavior intact so missed schedules do not backfill unexpectedly

Test Plan

python -m pytest tests/cron/test_jobs.py::TestGetDueJobs -q -o addopts= — 10 passed
python -m pytest tests/cron/test_jobs.py -q -o addopts= — 81 passed
python -m pytest tests/cron -q -o addopts= — 375 passed

alt-glitch · 2026-05-20T00:08:04Z

Duplicate of #28941 — identical title and approach (repair migrated timezone offsets in cron next_run_at). Also see #28951 for an alternative UTC-normalization approach. All fix #28934.

teknium1

Thanks for the focused cron fix. I verified the premise against current main: _get_due_jobs_locked() still normalizes persisted next_run_at through _ensure_aware() at cron/jobs.py:1032 and then compares next_run_dt <= now at cron/jobs.py:1033, so #28934’s old-offset early-fire path is still present.

Problems

The new repair path should ignore naive legacy timestamps. In this PR, _repair_cron_next_run_timezone() compares next_run_dt.utcoffset() to now.utcoffset() without first requiring an aware stored timestamp. For naive datetimes, utcoffset() is None, so the repair can rebase a legacy naive cron next_run_at directly onto now.tzinfo. Current main’s _ensure_aware() has deliberate compatibility behavior for naive timestamps at cron/jobs.py:295-311: interpret them as system-local wall time, then convert to Hermes time.

Suggested changes

Return None from the repair helper when next_run_dt.tzinfo is None or now.tzinfo is None.
Add a regression test for a naive legacy cron next_run_at so the old compatibility semantics stay protected.

Salvageability is high: the reported bug is real, the diff is small, and the fix likely only needs this guard plus a test. Automated hermes-sweeper review.

teknium1 · 2026-06-15T14:11:58Z

+    schedule = job.get("schedule", {})
+    if schedule.get("kind") != "cron":
+        return None
+


Please guard this helper to aware stored timestamps only. For legacy naive next_run_at values, utcoffset() is None, so this branch treats them as mismatched and can bypass the existing _ensure_aware() compatibility behavior that interprets naive timestamps as system-local wall time.

@Tranquil-Flow

A recurring cron job persists `next_run_at` as an absolute timestamp with a UTC offset (e.g. `2026-05-19T21:00:00+10:00`). Cron expressions, however, describe *local wall-clock* intent ("run at 21:00"). When Hermes/system timezone changes after the timestamp was persisted, the stored instant is re-interpreted in the new zone: `21:00+10:00` is the instant `13:00+02:00`, which is `<= now` (13:02+02:00) — so the job fires HOURS EARLY, then `compute_next_run` advances it via croniter to `21:00+02:00` the same day, producing a SECOND fire. (#28934, recurrence of #24289.) `_get_due_jobs_locked` now detects this precise migration case before the due check: for a `cron` job whose converted instant looks due, whose stored UTC offset differs from the current zone's, AND whose stored *wall-clock* time is still in the future (distinguishing a migrated offset from a genuinely missed run), it recomputes `next_run_at` from the schedule and skips the early fire — preserving the local wall-clock intent. Verified against the issue's reproducer: stored `21:00+10` under runtime `+02:00` at wall-clock `13:02` is rescheduled to `21:00+02` instead of firing early + again. Salvaged from #28941 by @Tranquil-Flow (authorship preserved). Chosen over the alternative approaches (#28951 normalize-to-UTC, #28985 rebase-and-match) because UTC-normalization does not change the absolute-instant comparison and so does not fix the early fire, and this guard is the tightest: it only acts when all four conditions hold and reuses the existing `compute_next_run`. Fixes #28934

@Tranquil-Flow

A recurring cron job persists `next_run_at` as an absolute timestamp with a UTC offset (e.g. `2026-05-19T21:00:00+10:00`). Cron expressions, however, describe *local wall-clock* intent ("run at 21:00"). When Hermes/system timezone changes after the timestamp was persisted, the stored instant is re-interpreted in the new zone: `21:00+10:00` is the instant `13:00+02:00`, which is `<= now` (13:02+02:00) — so the job fires HOURS EARLY, then `compute_next_run` advances it via croniter to `21:00+02:00` the same day, producing a SECOND fire. (NousResearch#28934, recurrence of NousResearch#24289.) `_get_due_jobs_locked` now detects this precise migration case before the due check: for a `cron` job whose converted instant looks due, whose stored UTC offset differs from the current zone's, AND whose stored *wall-clock* time is still in the future (distinguishing a migrated offset from a genuinely missed run), it recomputes `next_run_at` from the schedule and skips the early fire — preserving the local wall-clock intent. Verified against the issue's reproducer: stored `21:00+10` under runtime `+02:00` at wall-clock `13:02` is rescheduled to `21:00+02` instead of firing early + again. Salvaged from NousResearch#28941 by @Tranquil-Flow (authorship preserved). Chosen over the alternative approaches (NousResearch#28951 normalize-to-UTC, NousResearch#28985 rebase-and-match) because UTC-normalization does not change the absolute-instant comparison and so does not fix the early fire, and this guard is the tightest: it only acts when all four conditions hold and reuses the existing `compute_next_run`. Fixes NousResearch#28934

@Tranquil-Flow

A recurring cron job persists `next_run_at` as an absolute timestamp with a UTC offset (e.g. `2026-05-19T21:00:00+10:00`). Cron expressions, however, describe *local wall-clock* intent ("run at 21:00"). When Hermes/system timezone changes after the timestamp was persisted, the stored instant is re-interpreted in the new zone: `21:00+10:00` is the instant `13:00+02:00`, which is `<= now` (13:02+02:00) — so the job fires HOURS EARLY, then `compute_next_run` advances it via croniter to `21:00+02:00` the same day, producing a SECOND fire. (NousResearch#28934, recurrence of NousResearch#24289.) `_get_due_jobs_locked` now detects this precise migration case before the due check: for a `cron` job whose converted instant looks due, whose stored UTC offset differs from the current zone's, AND whose stored *wall-clock* time is still in the future (distinguishing a migrated offset from a genuinely missed run), it recomputes `next_run_at` from the schedule and skips the early fire — preserving the local wall-clock intent. Verified against the issue's reproducer: stored `21:00+10` under runtime `+02:00` at wall-clock `13:02` is rescheduled to `21:00+02` instead of firing early + again. Salvaged from NousResearch#28941 by @Tranquil-Flow (authorship preserved). Chosen over the alternative approaches (NousResearch#28951 normalize-to-UTC, NousResearch#28985 rebase-and-match) because UTC-normalization does not change the absolute-instant comparison and so does not fix the early fire, and this guard is the tightest: it only acts when all four conditions hold and reuses the existing `compute_next_run`. Fixes NousResearch#28934

@Tranquil-Flow

A recurring cron job persists `next_run_at` as an absolute timestamp with a UTC offset (e.g. `2026-05-19T21:00:00+10:00`). Cron expressions, however, describe *local wall-clock* intent ("run at 21:00"). When Hermes/system timezone changes after the timestamp was persisted, the stored instant is re-interpreted in the new zone: `21:00+10:00` is the instant `13:00+02:00`, which is `<= now` (13:02+02:00) — so the job fires HOURS EARLY, then `compute_next_run` advances it via croniter to `21:00+02:00` the same day, producing a SECOND fire. (NousResearch#28934, recurrence of NousResearch#24289.) `_get_due_jobs_locked` now detects this precise migration case before the due check: for a `cron` job whose converted instant looks due, whose stored UTC offset differs from the current zone's, AND whose stored *wall-clock* time is still in the future (distinguishing a migrated offset from a genuinely missed run), it recomputes `next_run_at` from the schedule and skips the early fire — preserving the local wall-clock intent. Verified against the issue's reproducer: stored `21:00+10` under runtime `+02:00` at wall-clock `13:02` is rescheduled to `21:00+02` instead of firing early + again. Salvaged from NousResearch#28941 by @Tranquil-Flow (authorship preserved). Chosen over the alternative approaches (NousResearch#28951 normalize-to-UTC, NousResearch#28985 rebase-and-match) because UTC-normalization does not change the absolute-instant comparison and so does not fix the early fire, and this guard is the tightest: it only acts when all four conditions hold and reuses the existing `compute_next_run`. Fixes NousResearch#28934

@Tranquil-Flow

A recurring cron job persists `next_run_at` as an absolute timestamp with a UTC offset (e.g. `2026-05-19T21:00:00+10:00`). Cron expressions, however, describe *local wall-clock* intent ("run at 21:00"). When Hermes/system timezone changes after the timestamp was persisted, the stored instant is re-interpreted in the new zone: `21:00+10:00` is the instant `13:00+02:00`, which is `<= now` (13:02+02:00) — so the job fires HOURS EARLY, then `compute_next_run` advances it via croniter to `21:00+02:00` the same day, producing a SECOND fire. (NousResearch#28934, recurrence of NousResearch#24289.) `_get_due_jobs_locked` now detects this precise migration case before the due check: for a `cron` job whose converted instant looks due, whose stored UTC offset differs from the current zone's, AND whose stored *wall-clock* time is still in the future (distinguishing a migrated offset from a genuinely missed run), it recomputes `next_run_at` from the schedule and skips the early fire — preserving the local wall-clock intent. Verified against the issue's reproducer: stored `21:00+10` under runtime `+02:00` at wall-clock `13:02` is rescheduled to `21:00+02` instead of firing early + again. Salvaged from NousResearch#28941 by @Tranquil-Flow (authorship preserved). Chosen over the alternative approaches (NousResearch#28951 normalize-to-UTC, NousResearch#28985 rebase-and-match) because UTC-normalization does not change the absolute-instant comparison and so does not fix the early fire, and this guard is the tightest: it only acts when all four conditions hold and reuses the existing `compute_next_run`. Fixes NousResearch#28934

@Tranquil-Flow

A recurring cron job persists `next_run_at` as an absolute timestamp with a UTC offset (e.g. `2026-05-19T21:00:00+10:00`). Cron expressions, however, describe *local wall-clock* intent ("run at 21:00"). When Hermes/system timezone changes after the timestamp was persisted, the stored instant is re-interpreted in the new zone: `21:00+10:00` is the instant `13:00+02:00`, which is `<= now` (13:02+02:00) — so the job fires HOURS EARLY, then `compute_next_run` advances it via croniter to `21:00+02:00` the same day, producing a SECOND fire. (NousResearch#28934, recurrence of NousResearch#24289.) `_get_due_jobs_locked` now detects this precise migration case before the due check: for a `cron` job whose converted instant looks due, whose stored UTC offset differs from the current zone's, AND whose stored *wall-clock* time is still in the future (distinguishing a migrated offset from a genuinely missed run), it recomputes `next_run_at` from the schedule and skips the early fire — preserving the local wall-clock intent. Verified against the issue's reproducer: stored `21:00+10` under runtime `+02:00` at wall-clock `13:02` is rescheduled to `21:00+02` instead of firing early + again. Salvaged from NousResearch#28941 by @Tranquil-Flow (authorship preserved). Chosen over the alternative approaches (NousResearch#28951 normalize-to-UTC, NousResearch#28985 rebase-and-match) because UTC-normalization does not change the absolute-instant comparison and so does not fix the early fire, and this guard is the tightest: it only acts when all four conditions hold and reuses the existing `compute_next_run`. Fixes NousResearch#28934

teknium1 · 2026-07-13T08:42:53Z

Thanks for the focused cron investigation and regression tests.

Automated hermes-sweeper review found this behavior is already implemented on current main:

cron/jobs.py:1951-1992 detects the old-offset, future-wall-clock cron case before dispatch, recomputes next_run_at from the cron expression, persists it, and skips the early fire.
cron/jobs.py:595-604 deliberately keeps naive legacy timestamps out of the offset-repair path so _ensure_aware() retains their compatibility semantics.
Commit f1f36b3bae2e1cfe96999e44689b41d3fd570f29 (fix(cron): repair migrated cron timezone offsets to prevent double-fire) implemented the fix, explicitly selected it over the alternative rebase-and-match approach in this PR, and is contained in v2026.7.1.

Closing as implemented on main.

@Tranquil-Flow

A recurring cron job persists `next_run_at` as an absolute timestamp with a UTC offset (e.g. `2026-05-19T21:00:00+10:00`). Cron expressions, however, describe *local wall-clock* intent ("run at 21:00"). When Hermes/system timezone changes after the timestamp was persisted, the stored instant is re-interpreted in the new zone: `21:00+10:00` is the instant `13:00+02:00`, which is `<= now` (13:02+02:00) — so the job fires HOURS EARLY, then `compute_next_run` advances it via croniter to `21:00+02:00` the same day, producing a SECOND fire. (NousResearch#28934, recurrence of NousResearch#24289.) `_get_due_jobs_locked` now detects this precise migration case before the due check: for a `cron` job whose converted instant looks due, whose stored UTC offset differs from the current zone's, AND whose stored *wall-clock* time is still in the future (distinguishing a migrated offset from a genuinely missed run), it recomputes `next_run_at` from the schedule and skips the early fire — preserving the local wall-clock intent. Verified against the issue's reproducer: stored `21:00+10` under runtime `+02:00` at wall-clock `13:02` is rescheduled to `21:00+02` instead of firing early + again. Salvaged from NousResearch#28941 by @Tranquil-Flow (authorship preserved). Chosen over the alternative approaches (NousResearch#28951 normalize-to-UTC, NousResearch#28985 rebase-and-match) because UTC-normalization does not change the absolute-instant comparison and so does not fix the early fire, and this guard is the tightest: it only acts when all four conditions hold and reuses the existing `compute_next_run`. Fixes NousResearch#28934

@Tranquil-Flow

A recurring cron job persists `next_run_at` as an absolute timestamp with a UTC offset (e.g. `2026-05-19T21:00:00+10:00`). Cron expressions, however, describe *local wall-clock* intent ("run at 21:00"). When Hermes/system timezone changes after the timestamp was persisted, the stored instant is re-interpreted in the new zone: `21:00+10:00` is the instant `13:00+02:00`, which is `<= now` (13:02+02:00) — so the job fires HOURS EARLY, then `compute_next_run` advances it via croniter to `21:00+02:00` the same day, producing a SECOND fire. (NousResearch#28934, recurrence of NousResearch#24289.) `_get_due_jobs_locked` now detects this precise migration case before the due check: for a `cron` job whose converted instant looks due, whose stored UTC offset differs from the current zone's, AND whose stored *wall-clock* time is still in the future (distinguishing a migrated offset from a genuinely missed run), it recomputes `next_run_at` from the schedule and skips the early fire — preserving the local wall-clock intent. Verified against the issue's reproducer: stored `21:00+10` under runtime `+02:00` at wall-clock `13:02` is rescheduled to `21:00+02` instead of firing early + again. Salvaged from NousResearch#28941 by @Tranquil-Flow (authorship preserved). Chosen over the alternative approaches (NousResearch#28951 normalize-to-UTC, NousResearch#28985 rebase-and-match) because UTC-normalization does not change the absolute-instant comparison and so does not fix the early fire, and this guard is the tightest: it only acts when all four conditions hold and reuses the existing `compute_next_run`. Fixes NousResearch#28934

@Tranquil-Flow

A recurring cron job persists `next_run_at` as an absolute timestamp with a UTC offset (e.g. `2026-05-19T21:00:00+10:00`). Cron expressions, however, describe *local wall-clock* intent ("run at 21:00"). When Hermes/system timezone changes after the timestamp was persisted, the stored instant is re-interpreted in the new zone: `21:00+10:00` is the instant `13:00+02:00`, which is `<= now` (13:02+02:00) — so the job fires HOURS EARLY, then `compute_next_run` advances it via croniter to `21:00+02:00` the same day, producing a SECOND fire. (NousResearch#28934, recurrence of NousResearch#24289.) `_get_due_jobs_locked` now detects this precise migration case before the due check: for a `cron` job whose converted instant looks due, whose stored UTC offset differs from the current zone's, AND whose stored *wall-clock* time is still in the future (distinguishing a migrated offset from a genuinely missed run), it recomputes `next_run_at` from the schedule and skips the early fire — preserving the local wall-clock intent. Verified against the issue's reproducer: stored `21:00+10` under runtime `+02:00` at wall-clock `13:02` is rescheduled to `21:00+02` instead of firing early + again. Salvaged from NousResearch#28941 by @Tranquil-Flow (authorship preserved). Chosen over the alternative approaches (NousResearch#28951 normalize-to-UTC, NousResearch#28985 rebase-and-match) because UTC-normalization does not change the absolute-instant comparison and so does not fix the early fire, and this guard is the tightest: it only acts when all four conditions hold and reuses the existing `compute_next_run`. Fixes NousResearch#28934

fix(cron): repair migrated timezone offsets

6f130c4

alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/cron Cron scheduler and job management duplicate This issue or pull request already exists labels May 20, 2026

Jiahui-Gu mentioned this pull request May 20, 2026

fix(cron): prevent double-fire after timezone offset migration (#28934) #29218

Closed

2 tasks

teknium1 reviewed Jun 15, 2026

View reviewed changes

KratosLee-6 mentioned this pull request Jun 18, 2026

Consolidate live-time PRs around one ephemeral runtime context path #17476

Open

6 tasks

kshitijk4poor mentioned this pull request Jun 21, 2026

fix(cron): repair migrated timezone offsets to prevent double-fire #50034

Merged

teknium1 closed this Jul 13, 2026

teknium1 added the sweeper:implemented-on-main Sweeper: behavior already present on current main label Jul 13, 2026

JoaoMarcos44 mentioned this pull request Aug 17, 2026

fix(cron): record the timezone a cron schedule is evaluated in #88581

Open

4 tasks

Navigation Menu

Uh oh!

fix(cron): repair migrated timezone offsets - #28985

fix(cron): repair migrated timezone offsets#28985
ScubaSteeve wants to merge 1 commit into
NousResearch:mainfrom
ScubaSteeve:fix/cron-timezone-offset-migration

ScubaSteeve commented May 19, 2026

Uh oh!

alt-glitch commented May 20, 2026

Uh oh!

teknium1 left a comment

Uh oh!

teknium1 Jun 15, 2026

Uh oh!

teknium1 commented Jul 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

ScubaSteeve commented May 19, 2026

Summary

Test Plan

Uh oh!

alt-glitch commented May 20, 2026

Uh oh!

teknium1 left a comment

Choose a reason for hiding this comment

Problems

Suggested changes

Uh oh!

teknium1 Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

teknium1 commented Jul 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants