bug: Moving Event in a recurring session does not work #62
Comments
|
I was able to work around the issue like this: # Fix bug with moved recurring event:
# https://github.com/niccokunzmann/python-recurring-ical-events/issues/62
event_start = event['DTSTART'].dt
event_moved = False
for component in ical.walk():
if component.name == "VEVENT" and component["UID"] == event["UID"]:
recurrence_id = component.get('RECURRENCE-ID')
if recurrence_id:
event_moved = recurrence_id.dt == event_start
break
if event_moved:
logging.warning(f'Excluding moved event {event.get("SUMMARY")} because of ical library bug.')
continue |
|
Thanks for reporting it! |
|
I created #65 and can reproduce the error. The ICS file looks fine, so I think the is a read bug needing further investigation. Thanks again! |
Moved event not recognized - Issue #62
|
This fix is included in v0.2.1 upwards. |
|
This doesn't seem completely fixed. I have confirmed the attached ical file works, however, here's an example exported from Google Calendar that doesn't work. There are two events (one is all-day), each with 3 occurrences, repeated weekly. The second occurrence on each event has been moved back 1 day. Here's what that looks like in Google Calendar:
Here it is correctly imported into Apple Calendar:
So to summarise, the 15th instance was moved to the 14th, and the 17th was moved to the 16th. Processing with this lib results in 3 events on the 14th, 15th, and 22nd for the first event, and 16th, 17th, and 24th for the second event. If I had to guess, it's generating the event on the right days (14th and 16th), but instead of replacing the corresponding instances (15th and 17th) it's replacing the first instance (8th and 10th). Here's the ical on its own: Here's a python script that shows the problem: from datetime import datetime
import recurring_ical_events
from icalendar.cal import Calendar
content = """BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:Test Calendar
X-WR-TIMEZONE:Australia/Sydney
BEGIN:VTIMEZONE
TZID:Australia/Sydney
X-LIC-LOCATION:Australia/Sydney
BEGIN:STANDARD
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
TZNAME:AEST
DTSTART:19700405T030000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
TZNAME:AEDT
DTSTART:19701004T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Australia/Sydney:20230808T140000
DTEND;TZID=Australia/Sydney:20230808T150000
RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20230828T135959Z;BYDAY=TU
DTSTAMP:20230629T040023Z
UID:7v3ju5ft4je5iq18nfdk2s3spk@google.com
CREATED:20230629T035454Z
LAST-MODIFIED:20230629T035851Z
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Datetime
TRANSP:OPAQUE
END:VEVENT
BEGIN:VEVENT
DTSTART;TZID=Australia/Sydney:20230814T140000
DTEND;TZID=Australia/Sydney:20230814T150000
DTSTAMP:20230629T040023Z
UID:7v3ju5ft4je5iq18nfdk2s3spk@google.com
RECURRENCE-ID;TZID=Australia/Sydney:20230815T140000
CREATED:20230629T035454Z
LAST-MODIFIED:20230629T035851Z
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Datetime
TRANSP:OPAQUE
END:VEVENT
BEGIN:VEVENT
DTSTART;VALUE=DATE:20230810
DTEND;VALUE=DATE:20230811
RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20230830;BYDAY=TH
DTSTAMP:20230629T040023Z
UID:6ep37v20d728v14rcgn17v9is6@google.com
CREATED:20230629T035522Z
LAST-MODIFIED:20230629T035854Z
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:All Day
TRANSP:TRANSPARENT
END:VEVENT
BEGIN:VEVENT
DTSTART;VALUE=DATE:20230816
DTEND;VALUE=DATE:20230817
DTSTAMP:20230629T040023Z
UID:6ep37v20d728v14rcgn17v9is6@google.com
RECURRENCE-ID;VALUE=DATE:20230817
CREATED:20230629T035522Z
LAST-MODIFIED:20230629T035854Z
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:All Day
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR
"""
cal = Calendar.from_ical(content)
events = recurring_ical_events.of(cal).between(
datetime(2023, 8, 1), datetime(2023, 8, 30)
)
for event in events:
print(event["SUMMARY"], event["DTSTART"].dt)Script output: |
|
Thanks for reporting this. I think the way you reported it, it is so clear that it can be tested and implemented.
|
|
@niccokunzmann The tests in that PR pass for me also. I am using 2.0.2 as well. I tracked down the issue to Sorry for the trouble, and thanks for working on this! |
|
Re-closing as this does appear to be fixed after all. |
|
Hi, thanks for reporting! I wonder what to improve in the workflow so that you could have read a hint to update... Where would you expect such a hint? Would you like this to depend on the icalendar package after a certain version or would it be nicer to run the tests locally? I think, fixing versions is something I would like the upstream to do but at the same time, this creates problems in downwards compatibility. This must be solved somewhere already. I think. What do you think?
|
|
Setting version of your dependencies is the correct way to solve this issue I think. It's not just about an upstream bug though, having a dependency without a version means someone could try using a really old version and have nothing work at all. But just in general, if lib A depends on lib B, but only works correctly with version 1.2.3 of lib B, then it should depend on >= 1.2.3 of lib B. |
|
The versions are now set in the requirements file. This was the last condition to close this, I believe. |
We're using [Polar.sh](https://polar.sh/niccokunzmann) so you can upvote and help fund this issue. We receive the funding once the issue is completed & confirmed by you. Thank you in advance for helping prioritize & fund our work.
The text was updated successfully, but these errors were encountered: