Bug#473632: periodic jobs miss a day on daylight-saving time spring change
On Mon, Mar 31, 2008 at 08:27:31PM +0200, Peter Eisentraut <peter_e@gmx.net> was heard to say:
> The periodic jobs (Apt::Periodic::*/cron.daily) miss a day on daylight-saving
> time spring change, because the current day's timestamp is compared to the
> previous day's and the job is skipped if the difference is less than 86400.
> You can fix that by replacing in /etc/cron.daily/apt
>
> # intervall is in days,
> interval=$(($interval*60*60*24))
>
> by
>
> # intervall is in days,
> interval=$(($interval*60*60*24-3600))
I wonder if it would be better to add "-u" to the "date" invocation.
That would solve this problem and also protect us from any other vagaries
of the local notion of time; e.g., I'm not aware of any localities where
the clock shifts by two hours, but it wouldn't surprise me if that's done
somewhere, or if it were to be adopted in the future. [0]
Of course, we'd have to add some indication in the timestamp file of
whether it was a UTC date or not, and add parsing code to the cron script
(otherwise a day might get dropped after the upgrade).
Another option, maybe in combination with "-u", would be to compare
the current calendar day with the previous calendar day.
Daniel
[0] in fact, Wikipedia says that some countries have experimented with
this in the past, although none are listed as currently practicing
it.
Reply to: