Differences in EXDATE calculations - how to achieve compatibility

Libraries
Log in to reply
  • niccokunzmann

    Hello,

    Purpose

    I am writing to you because I maintain a library for Python which handles repetitions of ICAL events. In an issue, an ics file was reported which my library does not handle “correctly”. I am writing to you because

    • I think, your software generated this file
    • I am not sure if I am too strict with the specification or you are more relaxed about it
    • We have incompatibilities for the EXDATE property in both our libraries and I would like to resolve this.

    Observations

    In Issue 20, this file is reported, see the Appendix.
    Excerpt:

    BEGIN:VEVENT
[...]
DTSTART;TZID=Europe/Berlin:20191015T161500
RRULE:FREQ=WEEKLY;UNTIL=20200204T151459Z;BYDAY=TU;WKST=SU
EXDATE:20191015T141500Z,20191022T141500Z,20191105T151500Z,[...]
END:VEVENT

    As you can notice, the DTSTART property is in Europe/Berlin time and the EXDATE properties end with a Z (UTC?).

    Problem: I generate the recurrence dates in Europe/Berlin times and they do not match the EXDATE times in UTC.

    The specification, it is unclear how to subtract the sets: If the time is in a different time zone but marks the same date/time, should it still be subtracted?

    The intuitive answer is yes, so you can specify recurrence dates as UTC and in different time zones as long as the the computed UTC-time stamp is the same.

    Please note that I am willing to implement a compatible solution to what seems to me your interpretation of the specification. However, I wanted to get back to you as this broader interpretation is not what I expected.

    Requests

    1. Can you write some thoughts on this?
    2. How did you decide you use different times zones for EXDATE and DTSTART, maybe even RDATE?

    Appendix

    BEGIN:VCALENDAR
PRODID:+//IDN bitfire.at//DAVx5/2.6.1.1-gplay ical4j/2.2.6
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
TZURL:http://tzurl.org/zoneinfo/Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:+005328
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:18930401T000000
RDATE:18930401T000000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19160430T230000
RDATE:19160430T230000
RDATE:19170416T020000
RDATE:19180415T020000
RDATE:19400401T020000
RDATE:19430329T020000
RDATE:19440403T020000
RDATE:19450402T020000
RDATE:19460414T020000
RDATE:19470406T030000
RDATE:19480418T020000
RDATE:19490410T020000
RDATE:19800406T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19161001T010000
RDATE:19161001T010000
RDATE:19170917T030000
RDATE:19180916T030000
RDATE:19421102T030000
RDATE:19431004T030000
RDATE:19441002T030000
RDATE:19451118T030000
RDATE:19461007T030000
RDATE:19471005T030000
RDATE:19481003T030000
RDATE:19491002T030000
RDATE:19800928T030000
RDATE:19810927T030000
RDATE:19820926T030000
RDATE:19830925T030000
RDATE:19840930T030000
RDATE:19850929T030000
RDATE:19860928T030000
RDATE:19870927T030000
RDATE:19880925T030000
RDATE:19890924T030000
RDATE:19900930T030000
RDATE:19910929T030000
RDATE:19920927T030000
RDATE:19930926T030000
RDATE:19940925T030000
RDATE:19950924T030000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
TZNAME:CEMT
DTSTART:19450524T010000
RDATE:19450524T010000
RDATE:19470511T020000
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19450924T030000
RDATE:19450924T030000
RDATE:19470629T030000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19460101T000000
RDATE:19460101T000000
RDATE:19800101T000000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20191219T182547Z
UID:f0f31ddb-6918-46af-a5a1-0a7254fbce71
SEQUENCE:11
SUMMARY:Test
LOCATION:Example
DTSTART;TZID=Europe/Berlin:20191015T161500
DURATION:PT1H30M
RRULE:FREQ=WEEKLY;UNTIL=20200204T151459Z;BYDAY=TU;WKST=SU
EXDATE:20191015T141500Z,20191022T141500Z,20191105T151500Z,20191119T151500Z,
 20191126T151500Z,20191203T151500Z,20191217T151500Z,20191224T151500Z,201912
 31T151500Z
CLASS:PUBLIC
STATUS:CONFIRMED
CREATED:20191013T184131Z
X-MOZ-GENERATION:10
END:VEVENT
END:VCALENDAR
    rfc2822 1 Reply 0
  • rfc2822
    developer

    Hello,

    @niccokunzmann said in Differences in EXDATE calculations - how to achieve compatibility:

    As you can notice, the DTSTART property is in Europe/Berlin time and the EXDATE properties end with a Z (UTC?).

    Z is UTC, yes (FORM #2: DATE WITH UTC TIME).

    Problem: I generate the recurrence dates in Europe/Berlin times and they do not match the EXDATE times in UTC.

    You always have to obey time zones. They are fundamental part of the iCalendar specification.

    The [specification], it is unclear how to subtract the sets: If the time is in a different time zone but marks the same date/time, should it still be subtracted?

    The specification is RFC 5545. The page you have linked to is a copy of RFC 2445, which has been obsoleted by RFC 5545.

    The intuitive answer is yes, so you can specify recurrence dates as UTC and in different time zones as long as the the computed UTC-time stamp is the same.

    Yes, that’s how I understand it, too (note that “floating times” are even more complicated; they are not associated to any time zone and thus don’t have a corresponding UNIX time stamp).

    Is there any indication that EXDATE/RDATE time zones are restricted to the same value as DTSTART/DTEND in the standard? In opposite, I see many hints that any DATE-TIME value is fine for EXDATE, when DTSTART is of type DATE-TIME.

    1. Can you write some thoughts on this?

    See above.

    1. How did you decide you use different times zones for EXDATE and DTSTART, maybe even RDATE?

    Android requires EXDATE always to be stored in UTC (for the reason you have noted above). So when DAVx⁵ reads the EXDATE from the database, it just prints it out as it’s there, because the server/other clients have to correctly calculate recurrences nevertheless and it’s one less step for DAVx⁵ which could cause errors.

    0
  • niccokunzmann

    Hi,

    thanks for your answer. This makes it much clearer to me. I will see what I can change in my library to comply.

    0
  • rfc2822
    developer

    Thanks. If you find any hint in the standard that EXDATE should always have the same time zone as DTSTART (what if DTEND has a different one?), please let me now 🙂

    0

Similar topics