RECURRENCE-ID and DTSTART should have same time zone



  • @rfc2822

    1. DAVdroid synchronizes this event:
    V/davdroid(32418): BEGIN:VEVENT
    V/davdroid(32418): DTSTAMP:20161019T112935Z
    V/davdroid(32418): UID:1hfhkjybp8u
    V/davdroid(32418): SEQUENCE:1
    V/davdroid(32418): DTSTART;TZID=Europe/Berlin:20161019T091500
    V/davdroid(32418): DURATION:PT1H
    V/davdroid(32418): RRULE:FREQ=DAILY;COUNT=3
    V/davdroid(32418): SUMMARY:Recur1
    V/davdroid(32418): STATUS:CONFIRMED
    V/davdroid(32418): CLASS:PUBLIC
    V/davdroid(32418): CREATED:20161019T131131
    V/davdroid(32418): END:VEVENT
    V/davdroid(32418): BEGIN:VEVENT
    V/davdroid(32418): DTSTAMP:20161019T112935Z
    V/davdroid(32418): UID:1hfhkjybp8u
    V/davdroid(32418): RECURRENCE-ID:20161020T071500Z
    V/davdroid(32418): SEQUENCE:1
    V/davdroid(32418): DTSTART;TZID=Europe/Berlin:20161020T091500
    V/davdroid(32418): DTEND;TZID=Europe/Berlin:20161020T101500
    V/davdroid(32418): SUMMARY:Recur1
    V/davdroid(32418): STATUS:CANCELLED
    V/davdroid(32418): END:VEVENT
    

    That’s exactly what’s DAVdroid has queried from the database (using the calendar provider): a recurring event, where the instance on **RECURRENCE-ID:20161020T071500Z** is marked as STATUS:CANCELLED.

    I don’t see any room for interpretation here or where you see a problem. Maybe I have overseen something, but in this case, I would need a specific report on what’s wrong.

    Sorry for picking up the old thread, but it fit pretty good to my problem.
    Who is writing the RECURRENCE-ID in this case?
    Because Recurrence-ID is given in utc and DTEND/DTSTART in lokal Time, whats produces duplicates and is standard.

    Below I paste the email communication between me and the infcloud developper:
    My question was:

    On 19 Jan 2019, at 19:00, Klaus wrote:

    Hi,
    Thank you for developing a frontend for Baikal!
    Infcloud runs on a Synology NAS with Baikal as a calendar server for appointments, addresses and tasks.
    Synchronization with Android clients make problems with recurring appointments, if they are edited and synchronized with Android calendar apps.
    If a single appointment is deleted from a recurring appointment, it will be correctly removed from the infcloud webpanel view.
    If a single appointment from a recurring appointment is only edited (start-/endtime edited), this recurrence will appear twice in infcloud. Once with the original time, the other time with the correct, new time.
    I did a bit of analysis and found that the parameter RECURRENCE ID is the problem. It is always in GMT caused by the Android Calender / Sync programs. Without specifying the time zone (example: RECURRENCE ID: 20190115T110000Z).
    Infcloud uses the specification in the local time:
    RECURRENCE ID; TZID = Europe / Berlin: 20190115T120000
    As an example, I have attached three ICS files, File 1 is the native appointment generated with infcloud. In File 2, the 15.01.2019 was changed by infcloud, in File 3, the 15.01.2019 was changed by Android. The result can be seen in the image files with the same name.
    Thunderbird, Android Calendar and Outlook are clear with this information (method) and display the dates correctly.
    Would it be possible to customize infcloud so that infcloud accepts dates in GMT times and displays no duplicates?

    His answer was:

    Gesendet: Samstag, 19. Januar 2019 um 20:46 Uhr
    Von: “Ján Máté” jan.mate@inf-it.com
    Betreff: Re: Problem with an appointment after sync with android clients
    Hi Klaus,

    according to RFC - https://tools.ietf.org/html/rfc5545 InfCloud behaviour is correct:

    3.8.4.4.  Recurrence ID
     
     
       Property Name:  RECURRENCE-ID
     
       Purpose:  This property is used in conjunction with the "UID" and
          "SEQUENCE" properties to identify a specific instance of a
          recurring "VEVENT", "VTODO", or "VJOURNAL" calendar component.
          The property value is the original value of the "DTSTART" property
          of the recurrence instance.
     
       Value Type:  The default value type is DATE-TIME.  The value type can
          be set to a DATE value type.  This property MUST have the same
          value type as the "DTSTART" property contained within the
          recurring component.  Furthermore, this property MUST be specified
          as a date with local time if and only if the "DTSTART" property
          contained within the recurring component is specified as a date
          with local time.
    

    and the RFC https://tools.ietf.org/html/rfc2119 (which defines the “MUST” keyword) says:

    1. MUST  
     This word, or the terms "REQUIRED" or "SHALL", mean that the
       definition is an absolute requirement of the specification.
    

    The VEVENT instance from your “File 3” (Android) looks like:

    BEGIN:VEVENT
    LAST-MODIFIED:20190119T112619Z
    DTSTAMP:20190119T112619Z
    UID:yr3smsul-rri3-y7ub-6iud-rsuqmv3f9gpw
    SUMMARY:Test Incloud
    STATUS:CONFIRMED
    RECURRENCE-ID:20190115T110000Z
    DTSTART;TZID=Europe/Berlin:20190115T120000
    DTEND;TZID=Europe/Berlin:20190115T140000
    LOCATION:Testhausen
    CLASS:PUBLIC
    TRANSP:OPAQUE
    SEQUENCE:1
    END:VEVENT
    

    => the DTSTART is specified in local time, but the RECURRENCE-ID in GMT => exactly the opposite of what RFC says.

    Cheers,
    JM


  • developer

    Should be fixed with https://gitlab.com/bitfireAT/ical4android/commit/c9948ade974cab4ca40ce4a18de002402602d9c3.

    I have sent an APK to your email address. Can you confirm that this version works for you?


  • developer

    Thanks for the confirmation over email. This fix will be included in the next version of DAVx⁵.



  • Great, thanks! 👍


Log in to reply
 

Similar topics

  • 4
  • 23
  • 4