The new snapd 2.25 has a new feature to set the refresh schedule within a 24h window. This allows to say that you want updates only between 4:00-7:00 in the morning for example or between 4:00-7:00 and 19:00-22:00.
The syntax is:
$ sudo snap set core refresh.schedule=4:00-7:00/19:00-21:00
Note that a refresh may happen outside of this window if your last refresh is too old, in this case snapd will refresh even outside the scheduled windows.
What or where is too old defined? I assume the idea is to keep end users from deciding to not ever refreshing. But good to know what “too old” means here.
While implementing something else I discovered that at first boot/last-refresh unset we decide to trigger a refresh immediately but through a slowish computation, I think we have two choices
shortcut: last-refresh unset => immediate refresh
last-refresh unset => compute the next refresh assuming last-refresh = midnight of the day before (or something similar)
for the default schedule these two are equivalent but for other schedules set through they gadget they might not be
trying to refresh as soon as possible after a first boot seems a good property and the device usually cannot be expected to be immediately available
A couple of observations and questions about refresh.schedule:
It appears by default the refresh.schedule option isn’t set to anything initially (ie. a get of refresh.schedule reports no key found if it’s never been snap set). If the user sets a schedule, how would they revert this change back to the original behavior?
I was able to set the refresh.schedule to a single time (eg. sudo snap set core refresh.schedule=4:00). Is this valid?
I was able to specify five time periods, is there a maximum number of time periods that can be set?
There doesn’t appear to be any validation of the supplied arguments, I was able to specify the following refresh schedules:
$ sudo snap set core refresh.schedule=12:00-11:00
$ sudo snap set core refresh.schedule=12:00-143:00
Note - all the above were observed with snapd 2.25.