Your import runs every day, but since the clocks changed, its report no longer arrives at the expected local time. The schedule might be doing exactly what it was configured to do: “every 24 hours” instead of “every morning at eight.” Those instructions coincide on many days. A change in the local UTC offset exposes the difference.
A dependable schedule starts with three decisions: Is the requirement a wall-clock time or an elapsed interval? Which time zone belongs to the task? What should happen when a local time does not exist or occurs twice?
Wall-clock time or elapsed interval?
A daily report for a team in Vienna belongs to a local time. In a five-field cron expression, 0 8 * * * means minute zero, hour eight, every day. With the time zone Europe/Vienna, the scheduled occurrence stays at 08:00 local time.
A recurring technical check often has a different requirement: scheduled occurrences should be 300 seconds apart, for example. An interval fits that requirement. Cronpimo calculates interval occurrences from a fixed starting anchor. It does not add the previous request’s runtime as an extra delay between occurrences.
86,400 seconds is exactly 24 hours, but not always one local calendar day. When Vienna moves to daylight saving time, the affected day has 23 hours; when it moves back, the day has 25. A fixed interval in seconds does not follow that change.
A concrete example from October 2026
The following comparison shows calculated occurrences in Europe/Vienna. The interval starts on 24 October at 08:00 and repeats every 86,400 seconds. The calendar schedule uses 0 8 * * *.
| Date | Calendar schedule | 24-hour interval |
|---|---|---|
| 24 October | 08:00 (UTC+02:00) | 08:00 (UTC+02:00) |
| 25 October | 08:00 (UTC+01:00) | 07:00 (UTC+01:00) |
| 26 October | 08:00 (UTC+01:00) | 07:00 (UTC+01:00) |
The calendar schedule has one 25-hour gap across this transition. The interval preserves its 24-hour gap and lands earlier on the local clock. A morning report usually calls for the calendar schedule; evenly spaced technical checks call for the interval. These are scheduled occurrences, not a promise that execution starts without any delay or has completed by that time.
Choose a named time zone
Europe/Vienna represents local time rules. UTC+01:00 represents only a fixed offset and contains no daylight saving rule. The IANA time zone database is updated when those rules change. Choose the zone of the business operation: Vienna for an Austrian end-of-day process, for example, or UTC for an exchange explicitly defined in UTC.
The executing agent’s location is a separate setting. A request from the United States does not turn a Vienna schedule into an American schedule. Display settings also matter: in Cronpimo, the account time zone can differ from the job’s scheduling time zone. The Suite displays occurrences in the account time zone with their UTC offset. Compare the complete timestamp and offset, rather than the hour alone.
What happens at 02:30?
In Vienna, 02:30 does not exist on 29 March 2026 because the clocks move forward. On 25 October 2026, 02:30 occurs twice. Schedulers do not all handle these cases the same way, so check the policy of the system you use.
Cronpimo’s calendar scheduler skips a nonexistent local time and considers only the first occurrence of a repeated local time. A daily 30 2 * * * schedule therefore has no occurrence on 29 March. On 25 October its occurrence is at 02:30 UTC+02:00; a second occurrence at UTC+01:00 is not scheduled.
That makes 02:30 a poor choice for a daily closing process that must not be missed. Choose a local time outside the transition window, or deliberately use a schedule defined in UTC. If every business day must be processed, the application should also identify missing work by business date. Scheduling alone does not provide that business-level check.
A short check before enabling the schedule
- Write the requirement explicitly: “every day at 08:00 in Vienna” or “every 300 seconds.”
- Select the matching calendar schedule and time zone, or interval and starting anchor.
- Inspect the upcoming occurrences in the preview. For a later clock change, test dates on both sides of that transition; the next five occurrences do not automatically cover every edge case.
- Distinguish scheduled start, actual start and successful completion. Allow for normal runtime and possible maintenance windows.
If an import must be finished by eight, eight is usually too late to start it. Allow suitable lead time and check completion separately. The cron job monitoring guide explains the different checkpoints. For work running on your own server, heartbeat completion signals can help. If an API exposes the latest result, also check its content and freshness.
A good schedule makes the expectation explicit. The result then tells you whether the expected work was actually completed.
Originally published on Cronpimo: Every morning at eight: choosing schedules and time zones.
Disclosure: This article and its cover were created with AI for Cronpimo. The scheduling examples were checked against Cronpimo’s current implementation and isolated tests.
Top comments (0)