If you go to daylight savings, the clock jumps from 2am to 3am.
No it doesn't. The clock ticks along as it always has done, in UTC. The timezone simply changes, which should be no big deal for timezone-aware applications.
The reverse happens, when you go back from daylight savings to regular time: the clock jumps from 3am to 2am. This means, all jobs between 2am and 3am run twice. I don't know, wether some cron implementation compensates for daylight savings.
From woody cron(8): Special considerations exist when the clock is changed by less than 3 hours, for example at the beginning and end of daylight savings time. If the time has moved forwards, those jobs which would have run in the time that was skipped will be run soon after the change. Conversely, if the time has moved backwards by less than 3 hours, those jobs that fall into the repeated time will not be re-run.
The root cause of this is of course that the crontab format is historic, and does not indicate what timezone should be used when interpreting it. Such design is always error prone. Good design would include a well documented way of including the timezone. Well, the above quote might even qualify. ;-)
Of course, using a 12-hour clock is also very error prone, but fortunately cron at least uses a standard 24-hour clock. No am/pm mess at least.
Camillo
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
