Tomorrow at nine is not always 24 hours away.
Choose between elapsed duration and a local clock appointment. Then inspect the transition dates, not just an ordinary day.
Two meanings of daily
Intervals count elapsed time. Cron matches wall time.
Start a rehearsal at 2026-10-31T09:00:00-04:00, in America/New_York. The local clock moves back the following day. The next occurrence for every 24h is 08:00 with offset −05:00; the next for every day 9am is 09:00 with offset −05:00.
| Intention | Input | First local occurrence |
|---|---|---|
| After 24 elapsed hours | every 24h | Nov 1, 08:00 −05:00 |
| At the local morning appointment | every day 9am | Nov 1, 09:00 −05:00 |
Neither is universally correct. A polling interval and a morning briefing express different intentions. Set the agent’s configured IANA zone explicitly; the visitor browser’s zone is not evidence of the Hermes host’s configuration.
Compare the autumn transition →A missing hour
The raw native value can name a nonexistent wall time.
With the pinned engine, a 30 2 * * * schedule starting after 03:00 on March 7, 2026 in New York returns 2026-03-08T02:30:00-05:00 for its next occurrence. Converting that instant through UTC back into the named zone gives 2026-03-08T03:30:00-04:00. There was no local 02:30 that morning.
MinuteField shows both values. The calendar places the normalized instant at 03:30 and flags the discrepancy. The event detail preserves the exact native return value. It does not silently relabel the raw value as a valid local time.
This is a boundary of the selected native calculation, not a promise about how a real gateway will behave. If that hour matters, choose an unambiguous time and test the real installation’s behavior.
Inspect the missing-hour example →A repeated hour
The starting offset distinguishes two identical clock readings.
At the autumn transition, 01:15 with −04:00 and 01:15 with −05:00 are different instants. That is why the starting field requires an explicit offset. A vague local clock reading would leave the scenario ambiguous.
For 30 1 * * *, the pinned sequence starting at 00:30 −04:00 returns 01:30 −04:00 and then the following day’s 01:30 −05:00. It does not necessarily enumerate both repeated-hour occurrences. Starting instead at 01:15 −05:00 finds the later 01:30 −05:00. Replacing the engine with a generic cron library can change this behavior.
Read the UTC instant in the event detail when two displayed clock times look identical. The calendar’s time label alone is not enough to disambiguate a fold.
Version matters
This tool uses selected Hermes 0.22.2 functions, croniter 6.0.0 and bundled timezone data from pytz 2026.3.post1. Future rule changes or a different installation can yield different dates. The method page records the exact source pin; the engine does not silently switch to the latest release.
References: configured-zone next-run implementation and September’s repeated-hour handling change. The earlier DST user report establishes a real checking task; its old behavior must not be attributed automatically to the current pinned release.