Should I worry about Daylight saving time when planning to schedule backups?

Question

So if there is a day:

https://secure.wikimedia.org/wikipedia/en/wiki/Daylight_saving_time

when we have to e.g.: set our clock back from 3am to 2am. Ok.

So if someone creates a cron job at 3am, then if a daylight saving day comes, the backup will run first at 3am, then the clock is automatically set back to 2am, 1 hour passes, then the backup runs again, because it's 3am! [and let's say, that there could be a problem, if the backup runs twice a day. or even worse: no backup will run, because it was e.g.: scheduled at 2am, but the clock never hits 2am, because it will be automatically set to 3am! when we have to set our clocks forward].

so the real Question: Are the daylight saving times are the same around the world, or are they in a different time? Should we take notice of this "theoretical" problem?

Answer 1

I don't know how Cron does it, but here's Microsoft's take on the problem with Task Scheduler.

Spring Forward

There are several possible ways that a scheduler program might behave for tasks that are scheduled in the time void that is caused by the SF transition:

• Method 1: Because those minutes do not appear for that day in that time zone, the scheduler may ignore any tasks that are scheduled to occur during those minutes. This behavior may be appropriate for some applications; the scheduler does not prevent those times from being placed in the schedule.

• Method 2: Start those tasks at the actual time that they would have been started, had DST not occurred. For example, a task that is scheduled to occur at 2:05 that morning would actually run at 3:05 DST. This approach may be useful for tasks that must be staggered and sequenced. However, this approach may cause one task to run after another task that is dependent on the first task. For example, if one task is scheduled at 2:30, and a followup task is scheduled at 3:15, the 3:15 task may run first, followed by the 2:30 task, which would now run at 3:30.

• Method 3: Compress time, and then run any missed tasks in the order that they were scheduled to run at some time after the transition. This behavior keeps tasks in order. However, if several tasks are scheduled during the SF time void, they appear to start almost simultaneously. Any interdependencies that require specific timing and sequence might cause failures of steps in the task. This appears to be the method that the latest Microsoft scheduler uses.

Fall Back

The following are several ways that a scheduler program might behave for tasks that are scheduled during FB, when time repeats:

• Method 1: Because the time repeats, do the task again each moment that the scheduled time occurs. This does not appear to be a common requirement; however, this behavior might be appropriate for some applications.

• Method 2: Start those tasks at the actual time that they would have started had DST not occurred. For example, a task that is scheduled for 2:05 that morning runs at the 1:05 standard time, which is the second 1:05 wall-clock time.

• Method 3: Start the tasks at the scheduled wall-clock hour. This behavior delays any tasks that are scheduled to start at 2:00 DST on that date for one hour, but all tasks beyond that time occur in the sequence and at the actual time interval that you want. The latest Microsoft scheduler appears to use this method. However, tasks that are scheduled to occur exactly at the transition moment may run at that moment. For example, a task that is scheduled to occur at 2:00 a.m. might run at 1:00 a.m. standard time (as in method 2).

Answer 2

Use UTC and you should have no problems. For CRON you can apparently do this:

/etc/default/rcS UTC=yes

as per http://ubuntuforums.org/showthread.php?t=497673