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 <da...@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 <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. 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 <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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel