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 <da...@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 <da...@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 >> <zbys...@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 <k...@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 >> | da...@davidstrauss.net >> | +1 512 577 5827 [mobile] > > > > -- > David Strauss > | da...@davidstrauss.net > | +1 512 577 5827 [mobile] -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel