Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Fri Feb 9 11:29:47 2007

I'd like to propose the following:

 http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#section-3.3.10

      The BYSETPOS rule part specifies a COMMA character (US-ASCII
      decimal 44) separated list of values which corresponds to the nth
      occurrence within the set of events specified by the rule.  Valid
      values are 1 to 366 or -366 to -1.  It MUST only be used in
+     conjunction with a BYDAY rule part.  For example "the last
-     conjunction with another BYxxx rule part.  For example "the last
      work day of the month" could be represented as:

        FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1

      Each BYSETPOS value can include a positive (+n) or negative (-n)
      integer.  If present, this indicates the nth occurrence of the
      specific occurrence within the set of occurences specified by the
      rule.

As the only usecase I can think of which isn't BYDAY is:

FREQ=MONTHLY;BYMONTHDAY=1,31;BYSETPOS=-1

But even that isn't terribly useful.  :o/  If you don't like the suggestion, perhaps you can enlighten me on it's utility outwith BYDAY?  Certainly all the examples in the spec use BYDAY.  Would I also be right in saying that the following rule would describe the last working day in March and February, or is it just March?

FREQ=YEARLY;BYMONTH=2,4;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1

Nigel

---

From: mikesamuel at gmail.com (Mike Samuel)
Date: Fri Feb 9 12:14:26 2007

To select the 15th and 30th of the month, but to substitute the 28 or
29th for 30th in February:

    RRULE:BYMONTHDAY=15,28,29,30;BYSETPOS=1,-1

mike

On 09/02/07, Nigel Swinson <[email-masked]> wrote:
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

---

From: mikesamuel at gmail.com (Mike Samuel)
Date: Fri Feb 9 12:24:20 2007

> FREQ=YEARLY;BYMONTH=2,4;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1

It's the last one in April :)

I believe
    FREQ=MONTHLY;BYMONTH=2,4;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
will give the last day in Feb and Apr, at least for our
implementation.  I'm a bit fuzzy on what effect the BYXYZ rule is
supposed to have when FREQ <= XYZ

---

From: benfortuna at gmail.com (Ben Fortuna)
Date: Fri Feb 9 17:03:39 2007

Mike,

Whilst I don't believe it is specified in RFC2445, I don't think it
makes sense for FREQ <= XYZ, where a BYXYZ rule is specified. FREQ
should always be greater than the BY* rules.

Correct me if I'm wrong. :)

regards,
ben

-- 
xmpp:[email-masked]
http://blogs.modularity.net.au/thenextbigthing

---

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Fri Feb 9 17:16:25 2007

>     RRULE:BYMONTHDAY=15,28,29,30;BYSETPOS=1,-1

Wouldn't it be better to write:

RRULE:FREQ=MONTHLY;BYMONTHDAY=-1,15

I know this is slightly different, but demanding the 30th rather than the 31st when available seems like a strange rule...

Nigel

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri Feb 9 17:18:08 2007

Hi Ben,

> Correct me if I'm wrong. :)

Correction: there is nothing to prevent this. In fact there are many 
examples where it is needed.

Take a look at Appendix A in Calconnect's recurrence recommendations 
document:

<http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf>

That shows a table illustrating how BYxx rules and FREQ work together to 
either limit or expand the set of instances in any one rule "iteration".

I think it would be useful to have something like this in 2445bis.

-- 
Cyrus Daboo

---

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Fri Feb 9 17:21:09 2007

> > I'm a bit fuzzy on what effect the BYXYZ rule is

If freq <= xyz, the Byxyz adds more entries to the set as detailed here:

      BYxxx rule parts modify the recurrence in some manner.  BYxxx rule
      parts for a period of time which is the same or greater than the
      frequency generally reduce or limit the number of occurrences of
      the recurrence generated.  For example, "FREQ=DAILY;BYMONTH=1"
      reduces the number of recurrence instances from all days (if
      BYMONTH rule part is not present) to all days in January.  BYxxx
      rule parts for a period of time less than the frequency generally
      increase or expand the number of occurrences of the recurrence.
      For example, "FREQ=YEARLY;BYMONTH=1,2" increases the number of
      days within the yearly recurrence set from 1 (if BYMONTH rule part
      is not present) to 2.

Cheers

Nigel

---

From: benfortuna at gmail.com (Ben Fortuna)
Date: Fri Feb 9 18:08:51 2007

Cyrus,

That expand/limit table is extremely useful. Would be great to see
that included in the RFC.

regards,
ben

---

From: mikesamuel at gmail.com (Mike Samuel)
Date: Mon Feb 12 09:56:48 2007

Nigel.

I agree that's easier but this is a recurrence rule used for certain
business rules that is expressible today, but not if the proposed
change goes into effect.

See http://www.google.com/search?q=15th+and+30th+of+the+month for
examples of where this rule is described.  It seems to be mostly used
as a way of expressing a bi-monthly deadline for receipt of forms.

cheers,
mike

---

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Mon Feb 12 10:55:23 2007

> as a way of expressing a bi-monthly deadline for receipt of forms.

Ok, interesting, but I still think it's a corner case that even if the standard supports, it is very unlikely that any gui will.  Even then if we are talking about businesses, then they work with working days rather than calendar days, so if the 30th or the 15th land on a weekend, then what they really mean is the next business day that lands after the 15th or the 30th, your rule doesn't catch that.

Here are other ways I think the rule is more usefully expressed:

RRULE:FREQ=DAILY;INTERVAL=15

RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=11,-1

RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=1,12

RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30
RDATE;VALUE=DATE:20070228,20080229,20090228,20090229,20100228

Even a google for BYSETPOS only returns 805 entries, so it can hardly be a commonly used part of the standard.  Compare that to BYMONTH which has 240,000 hits.

I'd be interested in hearing any other opinions on the proposal?

Nigel

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Mon Feb 12 10:58:34 2007

Hi Mike,

> as a way of expressing a bi-monthly deadline for receipt of forms.

Remember that there are always going to be rules that are hard or 
impossible to rally get to work with RRULE. Taking your example: what 
happens if the 15th or 30th is a weekend - one might expect the forms to 
come in the Friday before or perhaps the Monday after - then how do you use 
RRULE (remember only a single RRULE is now allowed in 2445bis)?

The fallback of course is to use a finite set of RDATEs that get "renewed" 
periodically as needed. That fallback could be used if Nigel's proposal 
were to be adopted.

I'm still tempted by the idea of having a new recurrence property to help 
with that. A property that indicates that the recurring event is 
"incomplete" and needs to be "renewed" at a certain date or beyond would 
certainly help in this situation. e.g. I could send out 12 months worth of 
"15th/30th or following Monday" events using RDATEs with the new property 
set to 20071231. In 2008, a client that sees such an event could alert the 
user that a refresh of it is required in some way. This idea has been 
discussed in the context of iTIP clients that cannot handle unbounded rules 
too.

-- 
Cyrus Daboo

---

From: mikesamuel at gmail.com (Mike Samuel)
Date: Mon Feb 12 12:20:26 2007

> RRULE (remember only a single RRULE is now allowed in 2445bis)?

I realize that.  The question was whether there were any examples that
were supportable now that would not be if the proposal were adopted
and that was the question I answered.

> periodically as needed. That fallback could be used if Nigel's proposal

This would be wonderful for supporting holidays and birthdays
calculated according to a lunar/lunisolar calendar.

---

From: mikesamuel at gmail.com (Mike Samuel)
Date: Mon Feb 12 12:38:21 2007

> Ok, interesting, but I still think it's a corner case that even if the standard supports, it is very unlikely that any gui will.  Even then if we are talking about businesses, then they work with w…

Nigel,

Yes, I agree that this is probably marginal but corner case is in the
eyes of the beholder and some business rules really are independent of
weekdays -- shipments are shipped and deliveries delivered based on
when things spoil which is independent of weekday.

And most business rules are adjusted based on ^(weekends U holidays).

That said, if you're going to ask for an example that doesn't use
BYDAY it seems perverse to reject examples because they don't filter
by day.

Very few calendar UIs allow creation of RRULEs with BYSETPOS, and most
uses of BYSETPOS that I've seen have been holidays and business rules
where the maintainer has some level of technical expertise.

> Even a google for BYSETPOS only returns 805 entries, so it can hardly be a commonly used part of the standard.  Compare that to BYMONTH which has 240,000 hits.

In this case I think you're right, but be very skeptical of comparing
hit counts http://www.searchengineshowdown.com/features/google/inconsistent.shtml#count