How Schedule handles the clocks going forward and back
Behind the scenes in Schedule by Zaweba: missing times, times that happen twice and repeating jobs across the spring and autumn clock changes.
Twice a year the clocks change, and twice a year badly written schedulers trip over it. Schedule by Zaweba has clear rules for both changes, chosen so a job never vanishes, never runs twice by accident, and never shortens or stretches the gap between repeats.
Timetables use the PC's local time, which is what you expect: a job set for 7:00 runs at 7:00 on the clock on your wall, summer or winter. The tricky part is the hour around each change, and that is where the rules come in.
The two awkward hours
In spring the clocks go forward. In the UK an hour is skipped, so some times on that night never happen at all. A job set for a time in the missing hour has no moment to run on the clock.
In autumn the clocks go back, and an hour happens twice. A job set for a time in that hour could, in principle, run at the first one, the second one or both.
Repeating jobs have their own problem. A job that runs every 15 minutes, if it counted by the clock face, could run three times in quick succession in autumn or leave a gap in spring.
What Schedule does
A fixed time that does not exist runs when the clocks have gone forward. The job is not skipped. It runs as soon as the clock has jumped, so a nightly job set inside the missing hour still happens that night.
A fixed time that occurs twice runs once. Your job does not run at the first occurrence and again an hour later.
Repeating jobs follow real time. Every 15 minutes is always 15 real minutes apart, whatever the clock says. Across the autumn change the job keeps its steady rhythm through the repeated hour, and across the spring change it does not leave a gap.
Why these rules are the right ones
Each rule protects the thing people actually care about. A nightly backup cares that it runs every night, so skipping it in spring would be wrong. A nightly report cares that it runs once, so running twice in autumn would be wrong. A job that polls every 15 minutes cares about the interval, so the gap must be real time.
Schedulers that get this wrong usually do so quietly. A job that ran twice may overwrite its own output, or send two emails, and nobody connects it to the clocks until the following year.
Checking it yourself
The timetable preview lists the next 10 run times for any job, in plain English or cron, so for a job near the change you can see its upcoming runs before you save. The run history records every run with its start and end times, what started it and how it ended, so after a change you can look back and see exactly what happened.
Tips for jobs near the change
Times between 1:00 and 2:00 in the morning are where the UK changes happen, and many people choose that time for nightly jobs because the PC is quiet. That is fine with Schedule, but if you want to avoid thinking about it at all, a time such as 3:00 or 4:00 sits outside the awkward hour.
If a job must run at a fixed interval measured in real time, use a repeating timetable rather than a list of fixed times. If a job must happen at a time on the clock, use a fixed time and let Schedule handle the edge cases.
Remember that jobs run while you are signed in to Windows. A change at night only matters if the PC is on and you are signed in then; if not, catch-up can run a missed job once as soon as Schedule is running again.
Quietly correct
Most of the year this feature does nothing visible, which is the point. Twice a year, Schedule by Zaweba does the sensible thing, and your history shows that it did.
