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. >> >> 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] -- 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
