PR #28941: fix(cron): repair migrated timezone offsets

• Repository: NousResearch/hermes-agent
• Author: Tranquil-Flow
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/28941

Description (problem / solution / changelog)

Summary

• prevent cron jobs from firing early after persisted next_run_at timezone offsets differ from the current Hermes timezone
• repair affected cron jobs by recomputing their next wall-clock occurrence before dispatch
• add regression coverage for migrated-offset double-fire behavior and stale already-passed wall-clock behavior

Related issue

Fixes #28934

Type of change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Refactor / cleanup
• Test-only change

Changed files

• cron/jobs.py
• tests/cron/test_jobs.py

Test plan

• Proved regression test fails without the production fix by temporarily restoring cron/jobs.py from upstream/main
• scripts/run_tests.sh tests/cron — 375 passed
• python -m py_compile cron/jobs.py tests/cron/test_jobs.py
• git diff --check

Full suite note: I attempted the canonical full scripts/run_tests.sh after installing .[all,dev], but this sandbox was killed with exit 137 around ~30% of the ~24k-test run. The focused cron suite and syntax/diff checks passed, and the failure mode appears to be the sandbox resource ceiling rather than this patch.

Details

When a Hermes deployment changes timezone offset, persisted cron next_run_at values can retain the old offset. Example: a job scheduled for 21:00+10 becomes 13:00+02 as an absolute instant. At 13:02+02, the scheduler sees the job as due and dispatches it early, then the next cron calculation schedules the intended 21:00+02 wall-clock run as well.

This patch detects that migrated-offset case narrowly:

• only for cron-triggered jobs
• only when the stored aware offset differs from the current Hermes offset
• only when the converted instant appears due but the stored local wall-clock time is still in the future

In that case, Hermes repairs next_run_at to the current timezone's next wall-clock occurrence and skips dispatch for the current tick. Already-passed stale wall-clock jobs keep the existing fast-forward behavior.

Checklist

• I have read the contributing guidelines
• I have added tests that prove the fix
• I have run relevant tests locally
• I have kept the change minimal and scoped

Changed files

• cron/jobs.py (modified, +48/-3)
• tests/cron/test_jobs.py (modified, +70/-0)

---

PR #28951: fix(cron): Normalize timestamps to UTC to prevent double-firing after timezone migration

• Repository: NousResearch/hermes-agent
• Author: shanewas
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/28951

Description (problem / solution / changelog)

PR: Fix Cron Double-Firing After Timezone Migration (#28934)

Summary

Fixes a sticky bug where cron jobs could double-fire after system timezone changes, DST transitions, or config/profile migrations.

Root Cause

_ensure_aware() interpreted naive timestamps using the current system local timezone. After any timezone shift, previously stored last_run_at / next_run_at values were re-interpreted, causing the scheduler to incorrectly consider jobs due again.

Changes

1. Core Fix (cron/jobs.py): Normalize all cron timestamps to UTC (industry standard).
2. Migration Helper: Added _migrate_timestamps_to_utc() — safe, idempotent, non-destructive migration for legacy naive timestamps.
3. Tests: Added TestCronTimezoneMigration covering naive and aware timestamp handling.

Testing

• All new tests pass.
• Existing cron test suite remains green.
• Manual verification: jobs no longer double-fire under simulated timezone shifts.

Security & Standards

• No new attack surface (pure datetime normalization).
• Follows existing error-handling and logging patterns.
• Migration is backward-compatible and non-destructive.
• Changes are minimal and highly auditable.

Linked Issue

Closes #28934

Commits on branch

• fix(cron): Normalize timestamps to UTC to prevent double-firing after timezone migration
• test(cron): Add regression tests for UTC timestamp normalization (#28934)
• refactor(cron): Add safe UTC migration helper for legacy timestamps (#28934)

Changed files

• cron/jobs.py (modified, +32/-13)
• tests/cron/test_compute_next_run_last_run_at.py (modified, +33/-0)

---

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

• Repository: NousResearch/hermes-agent
• Author: ScubaSteeve
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/28985

Description (problem / solution / changelog)

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

Fixes #28934

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

Changed files

• cron/jobs.py (modified, +63/-1)
• tests/cron/test_jobs.py (modified, +70/-0)