recurring appointments: exceptions not shown properly


  • Please find attached two more ics files.

    Test-1.ics: recurring appointment without exceptions
    Test-2.ics: recurring appointment with one exception on 06/10/17

    1_1507201257651_Test-2.ics 0_1507201257650_Test-1.ics

  • admin

    Thanks for reporting. We will have a look at it, it’s a bit stressy atm but we will not forget about it.


  • Did you find the time to have a look?

    Many thanks!


  • Sorry to push again, but this issue is quite “urgent” for me as I have a lot of appointments where some are rescheduled.
    And this means that there’re a lot of appointments in my ICSdroid calendar with no content.

    Thanks a lot for looking into this issue!

  • developer

    The three files are partially incomplete, don’t have VTIMEZONE (which is required for the Outlook timezone names) etc.

    Can you please provide exactly one full .ics file with an event and an exception which should be (but isn’t) processed by ICSdroid so that I can have a look?


  • The attached files are exported with Outlook. They include the VTIMEZONE, at least what I can see.

    1_1510518719859_test2-without-exceptions.ics 0_1510518719855_test2-with-exception-on-20171122.ics

  • developer

    @meiser Thanks. Which one shall I use to test?


  • The one with the exception.

  • developer

    I have sent an APK over email for testing. Please let me know whether it works for you.


  • It doesn’t work as expected. I answered by mail and sent my ics file which I used for testing.

  • developer

    @meiser Is “W. Europe Standard Time” your Android default time zone?


  • My Android time zone is “GMT+01:00 Mitteleuropäische Normalzeit”. The time zone is received by the mobile network, I enabled “Automatische Zeitzone - Vom Netzwerk angegebene Zeitzone beibehalten”.


  • I think, there’s a misunderstanding.

    It’s not that the exceptions are not shown at all, but they are not shown properly. The subject is “—”, the body and location field are empty.

    According to the screenshot which you sent me by mail, it’s also reproducable on your side. Could you please have a look?

    Many thanks!


  • Did you find the time to have a look again?

  • developer

    @meiser said in recurring appointments: exceptions not shown properly:

    It’s not that the exceptions are not shown at all, but they are not shown properly. The subject is “—”, the body and location field are empty.

    … as they are in the VEVENT (the one with the RECURRENCE-ID). I’m not absolutely sure about that, but as I understand it, the properties of the instance are completely defined by the propeties in the exception VEVENT. That means that if you want to have SUMMARY and other fields, you would have to repeat them for the exception VEVENT.

    I could not find a clear answer in the standards, but this is what I have seen in examples and what seems to make sense for me (for instance: how shall one know whether the SUMMARY has to be copied or whether it’s really empty?). I recommend to copy the required properties (SUMMARY, LOCATION etc.) to the exception VEVENT if you want to have it in the exception.


  • @rfc2822 said in recurring appointments: exceptions not shown properly:

    I recommend to copy the required properties (SUMMARY, LOCATION etc.) to the exception VEVENT if you want to have it in the exception.

    How shall I do it? This is how Outlook exports the calendar events to the ICS file. Or is there anywhere an option for Outlook to copy the required fields to the exception VEVENT which I didn’t find?

  • admin

    @meiser We don’t use and know Outlook, sorry - so we can’t look at it personally. I think when you make an exception in your Outlook calendar you should somewhere be able to fill the summary field, that would at least make sense or give users the option to have a different summary than the original VEVENT.


  • If I have an exception in the Outlook calendar, Outlook shows the same summary, location, body text as in the original VEVENT. So I don’t have to copy it over to the exception.

    Could you maybe implement a workaround for this issue? I don’t think that I can convince Microsoft to change its implementation.

  • developer

    @meiser said in recurring appointments: exceptions not shown properly:

    Could you maybe implement a workaround for this issue? I don’t think that I can convince Microsoft to change its implementation.

    We can of course think about that. But before doing so, I would at least like to know whether this change would be standards-compliant behaviour (and thus improve compatibility) or a workaround (which may reduce compatibility).


  • At https://icalevents.com/support/documentation/ics-guides/ under “Development and Testing Resources”, I looked at the “Tests for Recurrence Updates and Exceptions” (http://www.calconnect.org/tests/recurr_ical_streams.doc).

    In that doc, there’s an example for an exception. The only difference to the Outlook VEVENT is (from what I can see), the the SUMMARY is put into the VEVENT with the RECURRENCE-ID instead of the VEVENT with the RRULE.

    Chair reschedules a single instance’s (Tuesday’s) time portion +1 hr, so from 1000-1100 on Tuesday April 26, 2005.    This should yield a recurring meeting with following date/times:
    
    
    04/25/05	0900-1000
    04/26/05	1000-1100
    04/27/05	0900-1000
    04/28/05	0900-1000
    04/29/05	0900-1000
    
    
    Stream sent to invitee:
    
    BEGIN:VCALENDAR
    X-LOTUS-CHARSET:UTF-8
    VERSION:2.0
    PRODID:-//Lotus Development Corporation//NONSGML Notes 6.0//EN
    METHOD:REQUEST
    BEGIN:VTIMEZONE
    TZID:Eastern
    BEGIN:STANDARD
    DTSTART:19501029T020000
    TZOFFSETFROM:-0400
    TZOFFSETTO:-0500
    RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=-1SU;BYMONTH=10
    END:STANDARD
    BEGIN:DAYLIGHT
    DTSTART:19500402T020000
    TZOFFSETFROM:-0500
    TZOFFSETTO:-0400
    RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMONTH=4
    END:DAYLIGHT
    END:VTIMEZONE
    BEGIN:VEVENT
    DTSTART;TZID="Eastern":20050426T100000
    DTEND;TZID="Eastern":20050426T110000
    TRANSP:OPAQUE
    RDATE;TZID="Eastern";VALUE=PERIOD:20050426T100000/20050426T110000
    RECURRENCE-ID:20050426T130000Z
    DTSTAMP:20050406T205010Z
    COMMENT;ALTREP="CID:<FFFF__=0ABBE548DFE1E66E8f9e8a93d@coffeebean.com>":R
    eschedule of a single instance's time only (+ 1 hr)
    SEQUENCE:1
    ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN="iCal Chair/CoffeeBean"
    ;RSVP=FALSE:mailto:iCalChair@coffeebean.com
    ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION
    ;CN="iCal Participant/CoffeeBean";RSVP=TRUE
    :mailto:iCalParticipant@coffeebean.com
    CLASS:PUBLIC
    DESCRIPTION;ALTREP="CID:<FFFE__=0ABBE548DFE1E66E8f9e8a93d@coffeebean.com>":b
    ody
    SUMMARY:More complicated stream (5 day recurring)
    ORGANIZER;CN="iCal Chair/CoffeeBean":mailto:iCalChair@coffeebean.com
    UID:6BA1ECA4D58B306C85256FDB0071B664-Lotus_Notes_Generated
    END:VEVENT
    END:VCALENDAR
    

    So I think, it’s standards compliant to copy all properties like SUMMARY, LOCATION, etc. to the event exception.

Similar topics