Tags: recurrence

diesel, learning, evil, sweeti


And the third big ticket item for Data::ICal::DateTime was some refactoring of the recurrence-id stuff. I moved the stuff for unifying RECURRENCE-ID stuff into a seperate function collapse() which means that in EventQueue I can have a function which gathers all the events from all the providers and then collapses them where necessary. This is useful because that means I can add notes to other people's calendars for example.

    # $span is a DateTime::Span
    # $period is something like 'hour', 'day', 'month' etc etc
    my @events;
    foreach my $provider ($self->providers) {
        push @events, $provider->events($span);
    @events = Data::ICal::DateTime::collapse(@events);
    @events = map { $_->split_up($period) } @events if $period;
    return @events;
diesel, learning, evil, sweeti

Yet more ICalendar stuff

You see, the title is self-referential in a totally hip, ironic, post-modern kind of way. Because I keep talking about ICalendar stuff. And because it's also about recurring events in ICalendar stuff. And ... oh, forget it.

So, we can parse hideously complicated recurring dates like the London.pm date scheme now. Which is cool.

However what happens when you want to have note - i.e you want to automatically say that the meetings are on the first Thursday after a Wednesday every month but then, on Thursday the 8th you want to say "It's in the Prince Arthur"?

Well, the secret, apparently is in the Recurrence-IDs and UIDs.

Look at this ICalendar snippet

    SUMMARY:Test event
    SUMMARY:This is on a Tuesday

Notice how the two UIDs are the same and that the RECURRENCE-ID of the second event is the exactly one day later than the DTSTART of the first one (which recurs daily)?

All we have to do is keep a list of all the events belonging to a UID then if we find an event with a RECURRENCE-ID look up all the events with its UID, check to see if the start time is the same and, if it is, replace it.