Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So if there is a day:

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?

share|improve this question
Hm, I hadn't thought about that with my 2:30 AM backups... – Kromey Apr 28 '11 at 21:52
In what context are you asking the question? If you are developing a product, it should be easy enough to check if a backup is currently happening, or has happened recently. You might also look at interfacing with whatever library on the whatever system you are using implements DST, and see if you can work aground it. – Zoredache Apr 28 '11 at 21:55
just a unix/linux sysadmin – LanceBaynes Apr 28 '11 at 22:07
up vote 1 down vote accepted

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).

share|improve this answer
THANK YOU for the answer!! – LanceBaynes Apr 29 '11 at 0:06

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

/etc/default/rcS UTC=yes

as per

share|improve this answer
Or you could use 1:59 / 3:01 AM; the real issue is during the twilight zone between 2 and 2:59 – Mark Sowul Apr 28 '11 at 21:55
Just don't schedule backups between 2:00:00a-2:59:59a, do it at 3:00:00a or later. – LawrenceC Apr 28 '11 at 22:19
THANK YOU for the answer!! – LanceBaynes Apr 29 '11 at 0:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .