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

[David Strauss]

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.
>
> 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
>>
>>
>>
>> --
>> David Strauss
>>    | david at davidstrauss.net
>>    | +1 512 577 5827 [mobile]
>
>
>
> --
> David Strauss
>    | david at davidstrauss.net
>    | +1 512 577 5827 [mobile]



-- 
David Strauss
   | david at davidstrauss.net
   | +1 512 577 5827 [mobile]