Well, it took getting back to actually coding up something that works
for the new "dayofweekinmonth" functionality to remember one of the
reasons for my original proposal...
If we just add the one new value to the unit= argument
("dayofweekinmonth"), there is no way way to support the "last <weekday>
of the month" scenario. This is a widely used approach to recurring
dates. We can determine from the start= argument if the date in
question is the first, second, third or fourth (or even fifth, when it
exists) instance of <weekday> in a month, but there is no way to
determine that the user actually meant "last".
We can't just say we'll infer "last" from the fifth instance because
the user may well want to start the recurrence in a month that doesn't
have a fifth instance. There is no way for the user to tell us they
want the last instance each month.
I propose that we add a single additional argument to
#set_recurring_event called "weekinmonth" that is only used (and is
required) when unit=dayofweekinmonth. This argument can take the values
'first', 'second', 'third', 'fourth' and 'last'.
This is much more simple than my original proposal and utilizes the
idea in David and Yaron's approach of determining the weekday the user
wants from the start= value instead of creating yet another new argument
for that. It's also easy to handle in the code.
Thoughts?
-Al
On Thu, 2010-03-04 at 13:15 -0500, Yaron Koren wrote:
> Well, I think the basic 'xofmonth' functionality is the way to go - a
> single new value that takes care of everything. Assuming the new code
> works, I can add it in to SMW myself, since #set_recurring_event is
> basically my code. I'll probably wait until after SMW 1.5 is released,
> though...
>
>
> For the name of the new value, though, how about 'dayofweekinmonth'
> instead? It's quite long, but it's the only thing I can think of where
> there's even a remote chance that someone would understand it just by
> seeing the name.
>
>
> -Yaron
>
>
> On Thu, Mar 4, 2010 at 12:55 AM, David Raison <da...@hackerspace.lu>
> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hey,
>
> > Regarding the complexity of supporting the "2nd Wednesday of
> every 3rd
> > month" example: I agree it is likely to be a very rare
> occurrence.
> > However, I like it because it allows the "period" value to
> used with the
> > proposed new functionality in a way that is congruent with
> how it works
> > with existing functionality (I like consistency in my
> programmatic
> > interfaces).
>
>
> That is the point I was trying to make.
> I don't know about the 3rd Sunday every four months, but in
> our case, we actually have events that
> take place every first Saturday of a month, or every last
> Tuesday. (As can be seen by the real life
> example)
>
> If you have recurring events that the same people want to or
> shall attend, you can't have them
> attend them on different days of the Week every Month. That
> doesn't really work well with people's
> schedules.
>
> So all I ask for is really that X Day of every month, but as
> the period is already in there, why not
> let people have other periods.
>
> Of course, it might be more difficult/expensive to allow for
> events to recur on Easter every year
> (and I must admit I don't know exactly on what first/last day
> in what week that is) but Weekdays
> should come in pretty cheap and very handy for a considerable
> number of people. (We can't be that
> weird, having events recur on every first Saturday of a month,
> are we?)
>
>
> > David: I can certainly support your approach as well
> (especially since
> > it appears you've already got it coded.... 8^) ).
>
>
>
> Thanks ;) And it seems to me (knowing that there must be
> better algorithms) that this is pretty
> inexpensive. Even if you're off by a week on one round, the
> debt doesn't add up but is corrected in
> each loop. I first thought that this might not scale well with
> days in the first week of a month,
> but it actually does, doesn't it?
>
> D.
>
> - --
> HaxoGreen 2010 - the Hackers' Summercamp in Luxembourg
> July 22nd till July 25th 2010, in Dudelange, Luxembourg
> Register Now: http://events.hackerspace.lu/camp/2010/
> - ----
> mailto:da...@hackerspace.lu
> xmpp:kwis...@jabber.hackerspaces.org
> mobile: +43 650 73 63 834 | +352 691 44 23 24
> ++++++++++++++++++++++++++++++++++++++++++++
> Wear your geek: http://syn2cat.spreadshirt.net
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>
> iEYEARECAAYFAkuPSzYACgkQYTtdUdP5zDfltgCgkDnmKX1pBmXAmDSJbJFqeAg8
> nOwAoIRkkZGibn+RRSWJhUfxcp5zETum
> =5W8a
>
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find
> bugs
> proactively, and fine-tune applications for parallel
> performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
>
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
