I think the following In-Tran Data Directive would adjust running schedules to compensate for DST.
It works by looking at the SysAgentSched.LastRunOn
and SysAgentSched.NextRunOn
when the NextRunOn changes.
If LastRunOn is not during DST and the NextRunOn is during DST (going from STD to DST), then subtract 1 hour from the NextRunOn.
If going from DST to STD, add 1 hour.
here’s how
- Uses variables lastRun(DateTime), nextRun(DateTime), and dst_diff(Int).
- lastRun and nextRun were set via
Set Arg/Variable
widgets - dst_diff was set using the following code in a
Execute custom code
widget. - ttSysAgentSched.NextRunOn was set with the function
BpmFunc.AddInterval(ttSysAgentSchedRow.NextRunOn, dst_diff, IntervalUnit.Hours)`
Here’s the code for the Exec Cust Code block
DateTime lr = this.lastRun??DateTime.Now;
DateTime nr = this.nextRun??DateTime.Now;
TimeZoneInfo tzf=TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
DateTime lr2 = TimeZoneInfo.ConvertTime(lr , tzf);
DateTime nr2 = TimeZoneInfo.ConvertTime(nr , tzf);
if(!tzf.IsDaylightSavingTime(lr2) && tzf.IsDaylightSavingTime(nr2)){ // From EST -> EDT
this.dst_diff = -1;
}
else if(tzf.IsDaylightSavingTime(lr2) && !tzf.IsDaylightSavingTime(nr2)){ // From EDT -> EST
this.dst_diff = +1;
}
else{ // no change
this.dst_diff = 0;
}
You could add a UD field (a bool) to SysAgentSched and use that in a condition to determine if this schedule should be DST aware.
EDIT
There should be a condition added to not perform this on Interval type of schedules. Else you could try to set the next run prior to the last run, when the clocks are turned back.