Bug 77938

Timers with specify OnCalendar=hourly/daily/weekly/monthly currently assume 0 as parts of timestamp that are not specified. This results in timers elapsing at a predefined fixed time (full hour / midnight / Monday). I propose to allow for customization of that time, preferably by means of global settings. For example, a setting ElapseDailyTimers="05:20:00" would change the meaning of timestamp "daily" from "*-*-* 00:00:00" to "*-*-* 05:20:00". This would result in daily timers being fired at 5:20am, rather than at midnight. Note that the setting will be at a global level, not on a unit level. The name of the setting is just an example.

Rationale:
Distributions are beginning to replace cron tasks by systemd timers, a recent example being Arch Linux (please see [1]). The repository packages for various system maintenance utilities are being modified to include timer files, and these files typically specify OnCalendar timestamps as daily, weekly or monhtly. This has an unexpected consequence of all maintenance tasks shifting to midnight as opposed to early morning hours (4-6 am), as has been usual for cron tasks. Midnight is not an ideal time to run maintenance tasks (too early). In addition, in a multi-machine setup, this results in all machines performing their maintenance at or nearly the same time. There is now no way to spread these activities over a multiple hour period, as was possible by configuring cron separately on each machine. Please see [2] for description of a particular problem.
A similar argument can be given for weekly timers, for which Monday midnight may not be a preferable time, as well as for hourly and monthly timers.

Discussion of available workarounds:
The only workaround within systemd framework is to override timer files and replace OnCalendar timestamps with a specific time (e.g. "05:20" instead of "daily"). This is unfortunately quite cumbersome, as all services that use calendar timers would have to be modified that way, one by one. There is no way to change machine's maintenance time easily, as was possible with cron.
Another way is to avoid the use of systemd timers and continue the use of cron. Apart from this solution obviously going contrary to systemd spirit, it is becoming harder to implement as distributions are beginning to migrate from cron and will be removing it from base repositories and default installs.

Regression potential:
The regression potential of this change appears negligible, as we can keep the default "00" semantics and change it only when new settings are used.

[1] http://comments.gmane.org/gmane.linux.arch.devel/20644
[2] https://mailman.archlinux.org/pipermail/arch-general/2014-April/036019.html