Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions Clarification!)

From: [email-masked]
Date: Tue, 12 Jun 2001 16:26:29 -0400

I would like to take a second to clarify my current view of the changes 
for BYSETPOS before what I just sent is taken as a blanket acceptance of 
the proposed changes.

I just said:
>This can I live with as long as we expressly say to do this in the text 
for BYSETPOS 
>where we preclude it for FREQ values DAILY or smaller. 

This relates to the proposed change of Erics:

>  BYSETPOS MUST NOT be used with SECONDLY, MINUTELY, HOURLY or DAILY
>  rules.

As long as what I just sent jives w/the intent of Eric and Jonathan I can 
live w/this line (for the previously stated reasons and providing we add 
prose saying why its prohibited and what the alternative to BYSETPOS is 
for these FREQ cases (exploding into sub-rules).

I still do not agree w/the other bit from the proposed change:

>          If any of  BYSECOND, BYMINUTE or BYHOUR rule parts appear in a
>  rule, BYSETPOS MUST NOT appear.

Since it is still possible to generate a variable sized set of instances 
when they are present (to paraphrase Jonathans example):

RECUR:FREQ=MONTHLY;BYDAY=TU,TH;BYHOUR=9,12;BYSETPOS=-1,-4

which will generate between 16 and 20 instances.  The key to wheter or not 
BYSETPOS is actually allowed should be whether or not the instance set is 
variable in size; not whether or not a time BYxxx subcomponent is present.

Why not allow BYSETPOS if the time related BYxxx subcomponents?  Doesnt it 
make sense to allow BYSETPOS no matter which BYxxx subcomponents are there 
(as long as at least 1 non-time related one is)?

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