Subject: Re: Can we fix BYSETPOS?

From: [email-masked]
Date: Mon, 11 Jun 2001 17:59:54 -0400

Jonathan Lennox replied with:
>> 
>RECUR:FREQ=YEARLY;INTERVAL=100000000;BYSECOND=0,1,2,3,4,5,6,7,8,9,10,11,12,13,
>> > 14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,
>> > 37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59;
>> >        BYSETPOS=-1
>> >
>> >is a legal RFC 2445 recurrence.  It expands to approximately three
>> >quadrillion events before BYSETPOS is applied.  Good luck...
>> 
>> Thanks but by my calculations the set is 60 instances long (one per 
>> second) and the set repeats every 100000000 years.  The BYSETPOS simply 
selects the instance at second 59 
>> making the rest obsolete really.  Hmm, does Jonathan has a pet Dino?
>
>See, this is what I mean about BYSETPOS being confusing.

Clearly thats the root of much confusion.  I hope my previous posting on 
decoding helps shed some light on it.  If not, Ill defer to that thread to 
cover any further confusion.

>In RECUR:FREQ=MONTHLY;BYDAY=TU,TH;BYSETPOS=-1, the set is 8 - 10 
instances
>long, not 2.

Yes, depending on the the month.

>So in my example above, the set is three quadrillion instances long, not
>sixty.

The FREQ is yearly so that alone would make the entry repeat on a basis of 
1 year.  You do not factor in the INTERVAL value when trying to calculate 
the set; it is used when moving the starting point for the next 'rollout'. 
 As such, the only modifier you have to worry about is the BYSECOND. 

So since your DTSTART date/time value is only being 'expanded' using 
BYSECOND, the only part of it that will be changed (and added to the 
'set') is the seconds value of the time.  For example, had you provided a 
DTSTART;TZID=US-Eastern:20010611T090000 then the 'set' would evaluate out 
to:

11-Jun-2001 09:00:[00, 01, 02, 03, 04,..., 58, 59] EST

and since the DTSTAMP already used 09:00:00 that is a duplicate that gets 
ignored in the counting.  In any case, the BYSETPOS=-1 then selects the 
11-Jun-2001 @ 09:00:59 EDT instance.  The next pass around the INTERVAL 
value is added to the DTSTART to get a (non-compliant) new starting point for evaulation of 11-Jun-100002001 @ 09:00:00 EDT.

>How are these not analogous?

I think the confusion you have is that you are factoring in the INTERVAL 
value for the set rollout when you should not.

Clearer now??

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

From:   [email-masked]
Date:   06/08/2001 01:12:27 PM AST
Subject:        Re: Can we fix BYSETPOS?

-- 
Jonathan Lennox
[email-masked]

---

From: "Graham Gilmore" <[email-masked]>
Date: Mon, 11 Jun 2001 18:25:28 -0400

----- Original Message -----
From: <[email-masked]>
To: "Jonathan Lennox" <[email-masked]>
Cc: "Eric Busboom" <[email-masked]>; <[email-masked]>
Sent: 11 June, 2001 17:59
Subject: Re: Can we fix BYSETPOS?

> value for the set rollout when you should not.

    If INTERVAL isn't used in calculating the set, then how would one
specify a set that was, for example, 2 months or 2 years long?  One
might want to modify the "last working day of the month" example to be
"last working day every 2nd month".  INTERVAL would seem the natural
choice for this.  Sure, I suppose you could specify every 2nd month
explicitly with a BYMONTH part, but then the content (not just the
expansion) of the RRULE becomes dependent on the DTSTART (i.e. which
months are 'every second month'?), which seems wrong somehow.

    Graham

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 11 Jun 2001 18:31:14 -0400 (EDT)

> 11-Jun-2001 09:00:[00, 01, 02, 03, 04,..., 58, 59] EST

Ah!  This is the thing I missed.  Again, a serious omission in the RFC 2445
examples.

I understood, from RFC 2445, the concept "information smaller than your
smallest BY* parameter, and smaller than your FREQ, should be obtained from
DTSTART".

The question is, what do you do for fields *larger* than your smallest
BY* parameter, but smaller than FREQ?

This is only relevant if there's a "gap" in the information.

For instance:
    DTSTART;TZID=US-Eastern:19970902T090000
    RRULE:FREQ=YEARLY;BYMONTHDAY=1

I had interpreted this as meaning
    ==> (1997 9:00 AM EDT) September 2, October 1
        (1997 9:00 AM EST) November 1, December 1
        (1998 9:00 AM EST) January 1, February 1, March 1
  ...

(I.e. treat the "gap" information as "wild" -- as if we had
BYMONTH=1,2,3,4,5,6,7,8,9,10,11,12.)

Instead, you're saying it's
    ==> (1997 9:00 AM EDT) September 2
        (1998 9:00 AM EDT) September 1
        (1999 9:00 AM EDT) September 1
  ...

(I.e. treat it the same as if we had BYMONTH=9.)

Note that the only RFC 2445 examples that address anything like this
question are the ones of the form
     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU
     ==> (1997 9:00 AM EDT)September 2,9,16,23,30
         (1997 9:00 AM EST)November 4,11,18,25
         (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31

In this example, we must treat the week of the month as "wild" --
i.e. BYDAY=TU is equivalent to BYDAY=1TU,2TU,3TU,4TU,5TU in a MONTHLY rule.
(And to BYDAY=1TU,2TU,...,53TU in a YEARLY rule.)

Is BYDAY "special" when it comes to filling in gaps, and in all other cases
the gap should be filled in from the DTSTART?  Or are gaps different than
times smaller than the smallest time unit mentioned in a BY*/FREQ?

A very close reading of the RECUR definition seems to show that your
interpretation -- the "BYDAY is special, gaps aren't" reading -- is
*probably* right, and I guess it allows slightly more generality.  However,
it certainly wasn't clear, or illustrated.

-- 
Jonathan Lennox
[email-masked]