[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl-datetime
Subject:    Re: Questions about Recurrence sets
From:       "Michael Fair" <michael () daclubhouse ! net>
Date:       2003-04-30 18:30:03
[Download RAW message or body]

Thanks so much for the response.

> Michael Fair wrote:
> ...
> >  - Label each occurence in some way (preferably numerically)
> >    so as to either to assign unique event numbers to each
> >    occurrence, or to at least assign an occurence ID so
> >    that a specific instance can be located and manipulated.
> >    (This also gets into support iCal which requires a
> >     VEVENT object specify a recurrence ID to numerically
> >     identify an individual instance)
> 
> That's another thing that's under discussion. There is no
> implementation yet.

I looked up exactly how iCal expects this to be done again as
I was kind of hazy on the whole thing before.
iCal defines that instances are identified by their start time
(in the iCal timestamp format of course).  There's a general 
UID to pick the "Event" (which has one or more occurences) 
and a "Recurrence-ID" to select the individual instance.

If you move an instance, you address it by its existing time,
specify the new time in the DTSTART field, and next time you
want to manipulate it the ID is now the new start time.

That's fairly reasonable and works well with +/- infinity.

> > I think I can envision a scheme where I make a "Recurring Event"
> > a Set of EventSets.  Each variation creates a break and splits
> > the existing Set to create more Sets to compensate for the
> > variations.  When the start/end dates of each Set instance
> > are all examined, the total span of all the sets continues
> > to be the same as the original defintion (unless the user
> > has changed either the start or end date since creation).
> 
> If I understand what you mean, that's how it works. You can combine
> recurring events to make new sets, and add or remove elements
> from them.

Well I guess a sample story would be best.
"Weekly Meeting" - Recurs Monday @ 10am UTC from now until infinity
.... A few months Pass ....
"Weekly Meeting" - Recurs Monday @ 11am UTC from now until infinity

So now what we have is a Recurring event that has two sets:
origin time to a few months - Recurs @ 10am
a few months to infinity    - Recurs @ 11am

Next they move say the "May 29th" meeting to "May 28th".

So now what we have is a Recurring event that has four sets:
origin time to a few months - Recurs @ 10am
a few months to "May 22nd"  - Recurs @ 11am
"May 22nd" to "May 29th"    - Recurs @ 11am
"May 29th" to infinity      - Recurs @ 11am


> > The only things I'm not sure about is the speed with which
> > a specific time frame can be determined whether or not it
> > conflicts with the "Recurring Event", the speed with which
> > all ocurrences within a given time span can be instantiated,
> > and the speed and ability to accurately identify instances
> > of the recurring event (especially if begins at -infinity
> > is allowed).
> 
> The speed depends on the implementation of each recurrence.
> A recurrence is calculated just for the time
> frame you need, such that the speed depends on the 
> "density" of the recurrence. For example, daily recurrences are 
> generally slower than yearly recurrences, just because they
> generate more occurences.

That's really cool.  I couldn't figure out a way to quickly
slice out some random section of the future without 
instantiating all the middle instances.  Of course I was also 
restricting myself to something that could be easily stored 
in the database and was especially focused on designs that
would allow an SQL query to perform the test.  Things like
"Every other" where the recurrences were referenced from
some starting point were especially difficult.  The 2nd 
wednesday of the month and the like which specified exact 
dates/times were much easier.

> I don't think accuracy is an issue (unless you find a bug).

Well it was really accuracy in relationships to labels.
For instance "the 3rd occurence" isn't very accurate if
the set begins at -infinity.  

Of course for my application -infinity doesn't exist.  All
events take place from some start date into the future.
 


Again, thanks for the feedback, this is really cool stuff.
Especially if I can efficiently augment particular 
instances in the set and move them to a different time
and still have the conflict checks "do the right thing".

Now all I need to do is find a way to store/retrieve the
sets from an SQL DB and to efficiently be able to test
new events/event modifications, or new recurring events, 
for conflicts against all exising events and existing 
recurring events in the database.

-- Michael --

[prev in list] [next in list] [prev in thread] [next in thread]