Ask Ubuntu is a question and answer site for Ubuntu users and developers. 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

My server (running ubuntu 8.04LTS server) reports the time as 9:38PM BST right now. BST (British Summer Time) is 1 hour ahead of UTC (or Greenwich Mean Time if you really want to confuse matters)

The act of parliament defines that we in the UK use BST for

the period beginning at one o'clock, Greenwich mean time, in the morning of the last Sunday in March and ending at one o'clock, Greenwich mean time, in the morning of the last Sunday in October.

No problems scheduling this in cron but I don't know what date format/timezone I should be using. Do I set it to move forward at 1AM but back at 2AM when it ends? That makes sense if the machine uses BST but then I worry that that cron will not trigger at 2AM because the system clock might get reset back to 1AM before it has a chance to trigger - thus making my script run 1 hour late.

Or does it just use UTC?

share|improve this question
up vote 2 down vote accepted

The answer lies in the cron sources (which you can get by apt-get source cron), particularly in the main loop at lines 159--272 of file cron.c.

crond sleeps for a minute, then wakes up and queries the system time, comparing it to its own idea of time (i.e., what time it would be if nothing altered the clock). Based on the difference between the actual and the expected time, crond takes different actions; two of them are relevant in your case:

  1. Time has leaped forward more than 5 minutes but less than 3 hours (DST starts): cron runs wildcard jobs scheduled at the actual time, and any job scheduled at a fixed time between the computed time and the actual time. Relevant source is at lines 221--247:

       * case 2: timeDiff is a medium-sized positive number,
       * for example because we went to DST run wildcard
       * jobs once, then run any fixed-time jobs that would
       * otherwise be skipped if we use up our minute
       * (possible, if there are a lot of jobs to run) go
       * around the loop again so that wildcard jobs have
       * a chance to run, and we do our housekeeping
      Debug(DSCH, ("[%d], DST begins %d minutes to go\n",
          getpid(), timeRunning - virtualTime))
      /* run wildcard jobs for current minute */
      find_jobs(timeRunning, &database, TRUE, FALSE);
      /* run fixed-time jobs for each minute missed */ 
      do {
         if (job_runqueue())
         find_jobs(virtualTime, &database, FALSE, TRUE);
      } while (virtualTime< timeRunning &&
          clockTime == timeRunning);
  2. Time has gone backwards less than 3 hours (DST ends): just run wildcard jobs, skip fixed-schedule jobs since they have already run. Relevant source is at lines 247--258:

     * case 3: timeDiff is a small or medium-sized
     * negative num, eg. because of DST ending just run
     * the wildcard jobs. The fixed-time jobs probably
     * have already run, and should not be repeated
     * virtual time does not change until we are caught up
    Debug(DSCH, ("[%d], DST ends %d minutes to go\n",
        getpid(), virtualTime - timeRunning))
    find_jobs(timeRunning, &database, TRUE, FALSE);

So, when entering DST, you should have no problem: your script will be run (either just before, or immediately after the time leap).

When exiting DST, there is a risk that your (fixed-time) job will be skipped, if you schedule it exactly at 1 o'clock. My suggestion would be to schedule the run either 1 minute before 1 o'clock, or at 2 o'clock (or after).

share|improve this answer
Brilliant, thanks! – Neil Trodden Sep 9 '10 at 13:44

You may try to toggle the UTC=no if it's yes or vice versa in /etc/default/rcS. To do this, run:

gksu gedit /etc/default/rcS
  • Change UTC=no to UTC=yes, or
  • Change UTC=yes to UTC=no.

Save the file, quit the text editor, and reboot your PC.

share|improve this answer
Can't do that! At the very worst, my script to update the web forums database to switch everyone to daylight saving (ie - show UTC rather than UTC+1) will run at 2am and then again (as I've set the clock backwards to 1am). The alternative is that it doesn't run as the OS may snap back to 1am on its own and my update works an hour later. I don't want to reboot and I certainly don't want to risk it rebooting twice. I just need to determine how the OS is going to interpret my cron timing given that the server is switching BST as well! – Neil Trodden Sep 4 '10 at 22:16
why not create a small script which creates a file on first run and only runs if file is not there? so cron can call the script 2x but the script will notice and the logic is only done 1x. – aatdark Sep 4 '10 at 22:33
I can see the workarounds but I'm thinking that I need an answer the question of how timezones are handled in cron. I often work around things I can't get to work but I'd like to increase my understanding too. Comment +1 – Neil Trodden Sep 5 '10 at 0:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.