Time zones and daylight saving can make a scheduled AI task run twice, run late, or not run. The classic cron documentation says jobs scheduled in the missing hour of a clock change never match, and jobs in a repeated hour run twice. Ask which time zone a schedule uses and how it handles clock changes.
What the cron manual says
The Linux crontab manual states this plainly. Non-existent times, such as the missing hours during a daylight saving conversion, will never match, so jobs scheduled in those times are not run. Times that occur more than once during the conversion cause matching jobs to run twice.
Many assistant schedulers are not literally cron, so you cannot assume the same behavior. But the underlying problem is the same. A schedule says "at 02:30 local time", and on one night each year in many regions that time does not exist, and on another night it happens twice.
Where the zone comes from
A schedule has a time zone, and it may come from one of several places:
- The user's device setting at creation time
- The user's profile in the service
- A zone chosen on the task itself
- The vendor's server default, often UTC
If the task was created on a laptop in one city and the owner later travels or moves, which zone applies? If a team shares a task, whose local time is it? These are product questions with product answers, and you want those answers in writing.
Questions to ask
- Is the time zone stored on each task, and can I see and edit it?
- How are nonexistent local times handled: skipped, shifted, or run at the next valid time?
- How are repeated local times handled: once or twice?
- Does the schedule change when a user changes device time zone?
- Can I schedule in UTC to avoid the issue entirely?
- Does the run log show the actual start time with its zone?
Practical guidance
| Situation | Suggested approach |
|---|---|
| Task must run at a fixed business hour | Use a local zone, avoid 01:00 to 03:00 slots |
| Task is a technical job with no human timing need | Schedule in UTC |
| Task writes or sends something | Design it to check whether it already ran today |
| Team shared task | Store one explicit zone on the task, not on a person |
Avoiding the small hours of the morning is the cheapest fix. Most clock changes happen overnight, so a job at 09:00 is unaffected, while one at 02:30 is a candidate for trouble.
Why this matters for AI tasks specifically
For a plain script, a double run can duplicate a file. For an assistant task with tools, a double run can duplicate a message, a ticket or a comment. A skipped run can also hide that a report your team relies on never arrived. And because assistants are often used by people who never wrote a cron line, they may not realize a time zone is involved at all.
Include a clock change in your acceptance test. Set a task two hours before the next change in your region if you can, or ask the vendor to explain behavior using their documentation. If they cannot describe it, assume it is untested.
Check logs with their zone
When reviewing a run history, make sure timestamps carry a zone or offset. A log that shows "02:30" with no zone cannot tell you which of the two 02:30s ran. Ask for ISO style timestamps with offsets, and confirm that exported logs keep them.
Safeguard is not a scheduler, but its free scan at gold.safeguard.sh/scan gives a baseline you can compare against after any scheduled automation changes your dependencies.
A worked example: the 2:30 a.m. task
A team schedules an assistant task at 2:30 a.m. local time to prepare a morning briefing. In many regions, on the night clocks move forward, the hour from 2:00 to 3:00 does not exist. Under cron's documented rule, a job in that missing hour never matches, so the briefing is not prepared. On the night clocks move back, the hour from 1:00 to 2:00 happens twice, and a job in it runs twice.
If the assistant's task posts the briefing to a channel, the team sees nothing in March and a duplicate in November. Neither failure sends an error. This is the cost of a schedule written in local time without a plan for clock changes.
Step by step: make a schedule robust
- Choose the zone on purpose. Pick UTC for technical jobs, and a named local zone for jobs tied to business hours. Store it on the task.
- Move the slot. If the task does not care about the exact time, schedule it at 09:00 or 14:00, away from the overnight window.
- Make it repeat safe. Have the task check whether it already produced today's output before producing it again.
- Add a heartbeat. Write a marker at the end of each run and check for it, so a skipped run is visible.
- Test with a date. If the product lets you simulate or set a date near a change, use it. If not, review documentation and ask the vendor.
- Review twice a year. Put the two change dates in your team calendar.
A table of zone choices
| Zone choice | Good for | Watch out for |
|---|---|---|
| UTC | Technical jobs, reports for global teams | Local expectations of "morning" shift by an hour twice a year |
| Fixed local zone | Business hour jobs | Skipped or doubled runs near clock changes |
| User device zone | Personal tasks | Changes when the user travels |
| Vendor default | Quick trials | Unclear, so confirm it |
Regions also differ in when, or whether, they change clocks, so a team spread across several should lean on UTC for anything automated.
Evidence for reviews
If an auditor or customer asks how you control scheduled automation, a short note covering zones, repeat safety and heartbeats shows that you considered it. Keep the note with your other automation controls.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a recurring check surfaces a change, and ask how your own automation failures would surface.
Quick check
Should I schedule AI tasks in UTC?
For technical jobs with no business hour requirement, yes, since UTC has no clock changes. For tasks tied to local business time, use the local zone and avoid overnight slots.
Does every scheduler behave like cron?
No. Cron documents specific behavior. Other schedulers may shift, skip or repeat differently, so ask the vendor and test.
Can a scheduled AI task detect its own missed runs?
Not reliably. Use an external heartbeat: a marker written at the end of each run and a separate check that flags a missing marker.
Sources
Last reviewed: 19 October 2026.
