[Plugin: amr ical events lists] Edited, recurring event shows up twice

Hi sorry I missed this – support feeds are not showing up in google feedreader from some reason. I’ll look into it.

Hi, I have looked into this and according to the RFC 5545 spec, I think the plugin is doing the right thing by what the ics file specifies. Although what is in the ics file is a bit confusing.:-), I guess due to changes over time.

I will explore this further, to see if there is a code change that should be made that would not ‘break’ other possibilities.

However the quick, short fix for you may be to ‘clean up’ those special teachings. Maybe when one wants to create the specific instance, change the recurring one to start the month after, then create the special instance for the immediate next month ? You may want to delete historical instances too. Reason is that your ics file will grow and grow over time – google issues all the old stuff, not just the future, and they all have to be read and parsed to determine if they are relevant to the current date range. Simple reduces error risk.
—————————
Allow me to explain this problem, (you might want to open your ics file in a notepad editor to see the data. And perhaps have a cup of coffe or some Yerba mate to get the brain ready)

Your main recurring rule created CREATED:20120423T150309Z but with modifications….
had an infinitely recurring rule
RRULE:FREQ=MONTHLY;BYDAY=4SU
starting DTSTART;TZID=America/New_York:20120729T110000 (probably had some other start date back in time, judging by all the exceptions)
identified by
UID:[email protected]

that should generate instances as follows:

20120729
20120826
etc

Then come the modifications which are identified/matched by the UIDUID:[email protected]
and matched to the instance that they relate to by RECURRENCE-ID’s DATETIME.

EG The event below says “take the instance for 20120722T110000 and CHANGE it to 20120729T110000”
Now there currently is NO instance for 20120722T110000, so recurrence just gets added.

IF IT WERE to REPLACE the 20120729 instance, this

RECURRENCE-ID;TZID=America/New_York:20120722T110000

should rather be

RECURRENCE-ID;TZID=America/New_York:20120729T110000

Testing in some calendar apps, I see windows calendar does what the human expects, as does google if I reimport the calendar. In that they “rationalise” the two instances that have the same UID and date and time and length. While I could add such a check, I am wondering what would happen if one wanted to shift a previous instance to ‘overlap’ with another – like a catchup held at the same time in different location as the next instance? How should that be specified in a ics file ?

I’ve tried playing to create similar sets like you have, but cannot create that same data situation.

BEGIN:VEVENT
DTSTART;TZID=America/New_York:20120729T110000
DTEND;TZID=America/New_York:20120729T153000
DTSTAMP:20120802T072808Z
UID:[email protected]
RECURRENCE-ID;TZID=America/New_York:20120722T110000
CREATED:20120423T150309Z
..
LAST-MODIFIED:20120614T224715Z
..
SUMMARY:Special Teaching: Clear Light Mind and Buddha Nature
END:VEVENT

Specification References:

https://tools.ietf.org/html/rfc5545#section-3.8.4.4

recurid = “RECURRENCE-ID” ridparam “:” ridval CRLF

ridparam = *(
;
; The following are OPTIONAL,
; but MUST NOT occur more than once.
;
(“;” “VALUE” “=” (“DATE-TIME” / “DATE”)) /
(“;” tzidparam) / (“;” rangeparam) /
;
; The following is OPTIONAL,
; and MAY occur more than once.
;
(“;” other-param)
;
)

ridval = date-time / date
;Value MUST match value type

…..
Description: The full range of calendar components specified by a
recurrence set is referenced by referring to just the “UID”
property value corresponding to the calendar component. The
“RECURRENCE-ID” property allows the reference to an individual
instance within the recurrence set.
…

The DATE-TIME value is set to the time when the original
recurrence instance would occur; meaning that if the intent is to
change a Friday meeting to Thursday, the DATE-TIME is still set to
the original Friday meeting.

https://wiki.mozilla.org/Calendar:Recurrence_and_Exceptions
https://www.imc.org/ietf-calendar/mail-archive/msg06473.html

The Special Teaching actually occurs on the last Sunday of each month, but google’s recurring event scheduler doesn’t support “last.” That’s why we use the 4th Sunday as the recurring day.

There were 5 Sundays in July, so we changed the date of that occurrence from 7/22 to 7/29. I guess that’s the source of the problem, but I can’t follow why the ICS spec wouldn’t address that as expected.

If I understand your explanation, there should still be a recurring event instance 20120722T110000 that shows a date modification to occur on 7/29. You say that there is no such instance – but that appears to me to be a bug either in the spec or in google’s implementation.

That same instance could then have its description modified without creating an additional event.

Anmari,

One other thing please: why do the Sept and Dec occurrences show up correctly, when their dates were also changed from the original 4th Sunday? Does it have something to do with the SEQUENCE number?

hi, I had a more detailed look at this, created my own versions and eventually discovered – it’s not the exceptions that are a problem.. There’s a bug in the ‘nth’ day of week logic that is only being triggered in july 2012 – sunday. – which is why the exception doesn’t match it – dates are wrong – 29 instead of 22 ! (yes I know you wanted 29th anyway, but the 4th sunday logic should have been 22, until modified….

Exceptions, Sequence numbers are all okay

So fixing, and testing testing testing….. update will be up in a day or so

By the way – if you want to enter last x dayofweek of month recurring entries, you can do it using amr-events. Try it out at test.icalevents.com