[systemd-devel] Feature request: schedule jobs for last day of month

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 06, 2013 at 12:37:51AM -0800, David Strauss wrote:
> And, to bring this thread full-circle:
> 
> [Timer]
> Recurrence=FREQ=monthly;BYMONTHDAY=-1
> 
> That will run on the last day of each month.
> 
> On Wed, Feb 6, 2013 at 12:34 AM, David Strauss <david at davidstrauss.net> wrote:
> > Oh, one other current limitation is that it doesn't let you specify a
> > time zone since the code just uses the current time (effectively in
> > UTC) for DTSTART. We could support actual time zones if necessary by
> > having an additional field like TimeZone= that gets passed into the
> > "next event" calculation.
> >
> > I don't think this is a blocker.
> >
> > On Wed, Feb 6, 2013 at 12:27 AM, David Strauss <david at davidstrauss.net> wrote:
> >> Here is a version that is tested and, with review, I think ready to
> >> commit. This adds a unit test to exercise the "next event" logic,
> >> to/from string wrappers, and validity checks.
> >>
> >> This represents a near superset of existing scheduling. For example:
> >>
> >>  * "FREQ=minutely" will execute every minute, starting 60 seconds from
> >> when the unit started.
> >>  * "FREQ=minutely;BYSECOND=0" will execute every minute on the minute,
> >> starting the first time the clock shows 00 seconds.
> >>
> >> Of course, any other iCal RECUR syntax [1] is supported. The only
> >> notable exceptions are:
> >>
> >>  * Having a fixed recurrence count won't have any effect because we
> >> recalculate the start of the sequence every time systemd asks for the
> >> next occurrence. You can, however, specify an end date/time.
> >>  * For the same reason as the first exception, there's no ability to
> >> have a recurring event start its sequence in the future.
Hi,
I'm probably missing something, but if a start date and a count are set,
then it should be possible to calculate the next event (or if all are
now past) based on this data?

Zbyszek

> >> So, if you want to have an event run every minute during the third
> >> week of the year on odd hours between 9am and 5pm, except for the
> >> second to last occurrence, go for it:
> >>
> >> [Timer]
> >> Recurrence=FREQ=minutely;BYWEEKNO=3;BYHOUR=9,11,13,15;BYSETPOS=-1
> >>
> >> [1] http://www.kanzaki.com/docs/ical/recur.html
> >>
> >> On Tue, Feb 5, 2013 at 9:03 PM, David Strauss <david at davidstrauss.net> wrote:
> >>> I haven't tested this other than ensuring that it compiles with iCal
> >>> support (default) and with --disable-ical.
> >>>
> >>> I opted for putting the modularity into which sources get compiled,
> >>> like the gateway, which necessarily requires some #ifdefs in the timer
> >>> code. I could also put the modularity into the recurrence code itself.
> >>>
> >>> I looked at adding test code similar to the calendar set, but it's
> >>> mostly a parser tester. This parser library has its own test suite.
> >>> There still may be some room to test wrapper function like the next
> >>> time calculation.
> >>>
> >>> Also, no man page updates yet. I'd like to get the code in shape and
> >>> reviewed first.
> >>>
> >>> On Tue, Feb 5, 2013 at 7:34 PM, Zbigniew Jędrzejewski-Szmek
> >>> <zbyszek at in.waw.pl> wrote:
> >>>> On Tue, Feb 05, 2013 at 06:48:23PM -0800, David Strauss wrote:
> >>>>> On Tue, Feb 5, 2013 at 6:17 PM, Kay Sievers <kay at vrfy.org> wrote:
> >>>>> > Many of the things in iCal we *really* don't want or need, like the
> >>>>> > re-occurrence counters we would need to store and we likely don't want
> >>>>> > that kind of state, the time zones which I think we should entirely
> >>>>> > ignore for a system service, weird things like dependencies on the Mon
> >>>>> > vs. Sun start of the week.
> >>>>>
> >>>>> Recurrence counts don't require any state. iCal just computes N
> >>>>> recurrences since the start data and time. If they get missed, it's
> >>>>> handled the same way as if cron has a job scheduled for Sundays and
> >>>>> the computer is turned off that day. That said, I don't find this
> >>>>> capability too useful.
> >>>>>
> >>>>> Time zones actually can be useful for scheduling heavy jobs around low
> >>>>> utilization times. Work and utilization schedules follow DST changes.
> >>>> Also: send summaries of mailing list statistics on very first of the month,
> >>>> 12 am local time.
> >>>>
> >>>> Or: start syncing Fedora repositories on Jan 15 1 PM EST.
> >>>>
> >>>>> > It all sounds a bit like a "I do because I can" thing, because it
> >>>>> > looks easy to plug in a library that says it does all that, but is
> >>>>> > that really something needed and useful for a system service to
> >>>>> > schedule?
> >>>>>
> >>>>> The first question is if we want to support business-style scheduling
> >>>>> based on things like the "first Friday of the month" or "10 days
> >>>>> before the end of the trimester." If so, iCal RECUR is the obvious
> >>>>> path forward.
> >>>>>
> >>>>> It's not about being someone's personal calendar as much as
> >>>>> recognizing the role service scheduling has in business.
> >>>> Yeah, I think it is definitely at least worth investingating.
> >>>>
> >>>> Zbyszek