Olaf Dietsche wrote:
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
