I know in the past versions of VisualCron, the rolling forward and rolling back of the clocks for Daylight Saving Time (DST) would cause jobs set to run during that time (i think just when rolling the clocks ahead) to get in a stuck state because the time for a time trigger to run would never occur, so the 'next run time' would be in the past. I'm sure this has probably been asked a few times.. but we're currently in a mixed version environment with both 6.2.2 and 7.1.4 and both servers last night had a couple of jobs run twice. Reason for this, their time trigger is between 1am and 2am, and it ran the first time.... then at 2am the clocks got set back to 1am, and it ran again.

Maybe this has been taken into account in 7.5.0 beta, but i thought i'd ask. What is the current methodology when it comes to rolling the clocks ahead or back during DST time? Since rolling the clocks back double-runs the jobs, is there not some way each job could somehow take note of the last 10 or so runtimes so if the next runtime is a time that already occurred once, it wouldn't run again? So something like.. Trapping that at 1:15am on November 2nd, Job X executed. When 1:15am comes around again on November 2nd (because the clocks rolled back), it shouldn't run again.

Thoughts? Attached is a screenshot of a job running on 7.1.4, ran twice on the same day (1:15am) due to the DST rollback.

Brian

We have not seen this duplicate run before but will investigate this. Thanks.

---

Was this ever figured out? We just had a VisualCron instance do the same thing, where the 1 o'clock hour jobs were re-run. We are running 8.1.2, but will update to 8.2.x in the near future.
Thanks,

Thank you for your feedback! This has now been fixed for upcoming 8.3.0 release.

---

Thank you for your feedback! This has now been fixed for upcoming 8.3.0 release.

For the sake of understanding the thought process and/or coding behind it, can you possibly explain how it's being fixed from a logical perspective? I don't need the code, but high level 'we're doing X to avoid X'. Just curious how VC is compensating for the two scenarios.

1. Skipping a job when the clock rolls forward
2. Running a job twice if it falls between 1am and 2am.

DST clock changes are the one consistently lingering 'worry point' in the back of my mind twice a year haha. I just want to understand it so I can sleep better on those nights instead of babysitting our hundreds of jobs.

Thanks in advance!

Brian

Thank you for your feedback! This has now been fixed for upcoming 8.3.0 release.

For the sake of understanding the thought process and/or coding behind it, can you possibly explain how it's being fixed from a logical perspective? I don't need the code, but high level 'we're doing X to avoid X'. Just curious how VC is compensating for the two scenarios.

1. Skipping a job when the clock rolls forward
2. Running a job twice if it falls between 1am and 2am.

DST clock changes are the one consistently lingering 'worry point' in the back of my mind twice a year haha. I just want to understand it so I can sleep better on those nights instead of babysitting our hundreds of jobs.

Thanks in advance!

Brian

Yes, the problem was before that we recalculate Triggers whenever a time change occurs. This is fine when moving clock forward. But when moving clock backwards it will be scheduled to run again within the time period.

So, for the issue when we roll backward time we now do a number of checks as we cannot know if the time change was by a user, time server or something else. First we check so the adjusted time is 60 minutes. Then we check if the daylight savings value is different from last change;

Through this method:



If this is correct we skip the recalculation of Jobs. This means that it will run as scheduled before.

---

This year we had a change in the Brazilian Summer Daylight Savings time (Clocks Forward 1 hour), used to be changed in October, got pushed to November 4th.
We had to manually change the server clocks BACK 1 hour due to the automated change (Servers rolled the clock forward 1 hour in October 21st), at this point our VisualCron scheduled runs all triggered 1 hour ahead, VisualCron did not take into account the Servers clock changed, instead it is using it's own clock.
On November 4th when the real Daylight Savings began, the clocks were manually changed 1 hour FORWARD, now having the correct time, at this point, VisualCron AGAIN changed the schedules 1 hour forward.
So currently we have all our task executing 1 hour LATE.

Is there any command/configuration i can change in VisualCron to roll back 1 hour all Schedules ? Or i have to do it by hand ?

Daylight Savings time in Brazil ends February 16th, so i can't do with almost 3 months of 1 hour late in schedules.

I also would like to know what triggers the VisualCron rescheduling, is it a built in function ? A server trigger that is watched by the VisualCron ?

Thanks in advance.