Dear Maintainers,

the initial comments in apt.systemd.daily state:

  All of the n-days interval options also accept the suffixes
  s for seconds, m for minutes, h for hours, d for days or
  the "always" value to do the action for every job run,
  which can be used with systemd OnCalendar overrides to
  define custom schedules for the apt update/upgrade jobs.

This strongly suggests that a granularity below one day is possible.
That, however, is false because the check_stamp() function in that file
converts the modification date of the time stamp file as well as the
current time by first moving each back to the next 00:00 hours in the
local timezone before comparing the two. That gives an effective
granularity of one day; in particular, the resulting difference
(calculated by the script in seconds!) may be incorrect by up to
23 hours, 59 minutes and 59 seconds in either direction, an interval
of almost two days.

No motivation is given for this shift to midnight and in addition
comments in the file state that the calculation might fail sometimes in
certain timezones.

None of this seems necessary and the shifts should therefore be eliminated.
A proposed patch is attached which also removes two unnecessary "date"
calls used for recomputing the already-set variable "now".

The reason it does what it does exists, the cron job runs
once a day and if you compare the timestamps directly, and
the cron job happens to run 23:59:59 hours after the last time,
it wouldn't execute, hence it just compares the days.

The other timestamps were contributed at a later point but not tested,
only the 0 value was.

I have no intention of changing the behavior of these timestamps
because we really need to remove them entirely and rely on systemd.timer
execution settings, otherwise this never works reliable (and the
cron job for non-systemd systems will retain the existing behavior
as-is, it is a static target that should remain bug-compatible forever).

But this requires splitting up the services further to reasonable levels
of configurability and I haven't put any work into that yet.

Which is the reason why my apt configuration has included

  APT::Periodic::Update-Package-Lists "18h";

for some time (which only works with a modified apt.systemd.daily, of
course).

Note that, because Debian handles activation independent of the duration
variables in APT::Periodic, the meaning of the latter is different from
what a user might naively expect after reading the documentation: while
a description like

  APT::Periodic::Download-Upgradeable-Packages "0";
  - Do "apt-get upgrade --download-only" every n-days (0=disable)

in apt.systemd.daily suggests that these variables control activation,
they are in effect only variables to *suppress* the execution if the last
execution was too recent.

This also means that the current implementation permits at most one
execution per calendar day; see report #778873 for an example of someone
who wanted more (which would be trivial with systemd timers, provided
apt.systemd.daily were to be modified as I proposed or one were to
abolish these variables entirely).

I have no problem with that. After all, it's FOSS, and I can modify the
files on my systems. I just thought my proposal would be useful to
others as well (besides aligning with the documentation and eliminating
one unnecessary cause of runtime errors -- oh, and trivial to implement).

Regards,
Martin Lottermoser

I have taken my time to reply to your bug, and explain to you why it's not
trivial to change so please do not tell me it's trivial. It's there for
a reason and the reason doesn't suddenly go away if you chose to ignore
it.

The change you intend would not be trivial. My statements clearly refer
to *my* proposal, not yours, and measured by the length of the patch file
I have provided and that it affects a single file only I stand by my
claim that that change would be trivial.

I fail to understand what the "it" is you claim to be there for a reason
and what the reason is you claim I have ignored.

I'm sorry to have placed an excessive temporal burden on you; I'll try
to avoid that in the future by not reporting bugs any more.

Lottermoser