Differences in EXDATE calculations - how to achieve compatibility



  • 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
    

  • 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.



  • Hi,

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


  • 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 🙂


Log in to reply
 

Similar topics

  • 3
  • 9
  • 3