Robo-FTP User's Guide > Appendix > Daylight Savings Time Considerations for Scheduling

When using a custom CRON string, the schedule will always fire at a given time of day and then compute the next time to fire. If that time does not occur on a given day due to a daylight savings change ("spring forward"), the trigger will be skipped. If that hour happens twice ("fall back") the CRON schedule will still only fire once (on the first occasion). The hour from 2 - 3 AM will not occur during spring forward so you will need to manually execute or schedule a run once for any job using a CRON string that is supposed to run in that window.

A fixed interval schedule that fires at an interval of one day or greater, or a schedule that runs monthly or on specific days will automatically be corrected for daylight savings time. Consider the case where a job is scheduled to run once per day, starting at 6 A.M. Before and after the daylight savings change, the job will run at 6 A.M. local time. However, due to the daylight savings change, the time between runs in this scenario will be either 23 or 25 hours, depending on the type of change.

In the case of those schedules with an interval of one day or greater, when they are scheduled to fire during a time that does not occur (2 - 3 AM on "spring forward"), they will trigger an hour later on local time so they should require no intervention. For example, a job scheduled to run at 2:30 AM during "spring forward" will instead run at 3:30 AM.

However, fixed interval schedules that fire at an interval of less than a day are treated as daylight savings-agnostic and will continue to fire according to their pre-existing interval. These will thus appear an hour different after a DST change. If you do not desire this behavior for a particular job, you should switch it to a custom CRON string schedule.