bug: RRULE UNTIL UTC and ignored exdate

[KoljaWindeler]

Hi, first up: I really like your package. It works great for me in a lot of cases.
Sadly not all of them :)

The attached Zip contains 3 files.
t.ics (directly exported from calendar)
t2.ics (fixed the Timezone of the RRULE UNTIL)
test.py (test script)

running it as is (you'll have to change the path) will crash with the first error:
RRULE UNIT field is not in UTC ... the error is correct, the datetime is not in UTC, but according to my research on the web this was already fixed (seems to be OK that the until is local?)

But even with the fixed UNTIL (t2.ics) the EXDATE rule is ignored.
python3 homeassistant/test.py
start 2020-04-26 14:00:00+00:00 duration 0:30:00
start 2020-04-27 14:00:00+00:00 duration 0:30:00
start 2020-04-28 14:00:00+00:00 duration 0:30:00

is the output, but EXDATE:20200427T120000Z seems like line two shouldn't be there .. or am I understanding it wrong?

Thanks in advance!
Kolja

exdate.zip

---

We're using Polar.sh 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.

[niccokunzmann]

Hi, thanks for reporting this. #25 could be related - (I remember having worked on #25).

Also, since this is reproducible, it should be easy to follow the suggested implementation path which helps keeping the other functionality intact.

Suggested implementation

• add an ICS file, example:
  

  python-recurring-ical-events/test/calendars/issue-15-duplicated-events.ics

  Line 1 in f4a90b2

  BEGIN:VCALENDAR

• add a test, example:
  

  python-recurring-ical-events/test/test_issue_15.py

  Line 21 in f4a90b2

  def test_sequence_is_not_present(calendars):

• implement the test
• fix the test

---

At the moment, I do not have so much time. I can still help if you like to go forward changing this yourself. If you open a pull request, I will see all the changes you make and comment on them. Or you can wait for me to do it or pay me ;)

[niccokunzmann]

I also think, that there are several Issues we have:

• in t1 - a conversion happens which is not done properly
• in t2- the default time zone is not the same as the one used for the until value - adding a Z will make it UTC and as such not excluding the date. 925e966 fixes this by adding 2 hours - which might be incorrect.

[niccokunzmann]

@KoljaWindeler, so far, I could fix the tests in #32. However something is interesting:

Currently, the issue is that the time zone is not recognized.

These are the three dates:

start 2020-04-26 14:00:00+00:00 duration 0:30:00
start 2020-04-27 14:00:00+00:00 duration 0:30:00
start 2020-04-28 14:00:00+00:00 duration 0:30:00

But their start looks like this:
DTSTART;TZID=/freeassociation.sourceforge.net/Europe/Berlin: 20200426T140000

• https://www.kanzaki.com/docs/ical/tzid.html does not specify time zone naming

I think, this issue is out of scope of this repository. I think, this can be directed to the icalendar repository as I use that to parse the files.

[niccokunzmann]

I will close this issue now as I passed it on to the icalendar module. Please let me know if there is anything else or if that was partly a mistake.

[niccokunzmann]

This is solved in v0.1.18b