@rfc2822 https://gitlab.com/bitfireAT/davx5-ose/-/commit/e157322a1fcbd23c26263f31c2adb1218ec4843a
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
- Can you write some thoughts on this?
- 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
-
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 forEXDATE
, whenDTSTART
is of typeDATE-TIME
.- Can you write some thoughts on this?
See above.
- 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 theEXDATE
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.
-
Thanks. If you find any hint in the standard that
EXDATE
should always have the same time zone asDTSTART
(what ifDTEND
has a different one?), please let me now