Events created by DavDroid are very large



  • Dear all,

    I've noticed that events created via DavDroid are very large. I've created a simple test event (no recurrence etc.) in DavDroid as well as in CalDav Sync (dmfs) and observed:

    • the event created by CalDav Sync was 34 lines and 759 bytes,
    • the event created by DavDroid was 117 lines, 2582 bytes.

    As you can see, the (semantically) same event created by DavDroid is more than three times larger than in dmfs. As a user, I can't see a difference.

    In particular, DavDroid includes large daylight and standard definitions, e.g.

    BEGIN:DAYLIGHT
    TZOFFSETFROM:+0100
    TZOFFSETTO:+0200
    TZNAME:CEST
    DTSTART:19160501T000000
    RDATE:19160501T000000
    RDATE:19170416T030000
    RDATE:19180415T030000
    RDATE:19400401T030000
    RDATE:19430329T030000
    RDATE:19440403T030000
    RDATE:19450402T030000
    RDATE:19460414T030000
    RDATE:19470406T040000
    RDATE:19480418T030000
    RDATE:19490410T030000
    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
    

    Could someone explain what this is good for? Is this a bug or a feature?

    Thanks!



  • Can you provide greater detail? Both DAVdroid and CalDav Sync are data transfer tools, not event creators per se. What did you actually use to make the event, and how did you then access it?



  • Of course. The events were created with the standard Android 5.0 calendar app, the CalDAV implementation is SOGo. Steps to reproduce:

    1. Using Android 5.0 (Google Nexus 5 Factory Image), setup both CalDav and Davdroid using the same credentials.
    2. Open the standard Google calendar.
    3. Create an event for Wednesday 11th at 18:00-19:00 CET, subject "Test (DavDroid)". As calendar, choose the DavDroid one.
    4. Create an event for Wednesday 11th at 19:00-20:00 CET, subject "Test (dmfs)". As calendar, choose the DavDroid one.
    5. In SOGo, right click the appointsments to show their source.

    Results:
    Source (DavDroid)

    BEGIN:VCALENDAR
    PRODID:-//bitfire web engineering//DAVdroid 0.7 (ical4j 1.0.x)//EN
    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:19160501T000000
    RDATE:19160501T000000
    RDATE:19170416T030000
    RDATE:19180415T030000
    RDATE:19400401T030000
    RDATE:19430329T030000
    RDATE:19440403T030000
    RDATE:19450402T030000
    RDATE:19460414T030000
    RDATE:19470406T040000
    RDATE:19480418T030000
    RDATE:19490410T030000
    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:19450524T020000
    RDATE:19450524T020000
    RDATE:19470511T030000
    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:20150310T160707Z
    UID:20150310T160707Z-21040@65a4ba7c0eec5450
    DTSTART;TZID=Europe/Berlin:20150311T180000
    DTEND;TZID=Europe/Berlin:20150311T190000
    SUMMARY:Test (DavDroid)
    STATUS:CONFIRMED
    ORGANIZER;CN=xxxx@yyyy.de%20(DAVdroid):mailto:xxxx@yyyy.de%20(DAV
     droid)
    LAST-MODIFIED:20150310T160707Z
    CLASS:PUBLIC
    END:VEVENT
    END:VCALENDAR
    

    Result (dmfs):

    BEGIN:VCALENDAR
    PRODID:-//dmfs.org//mimedir.icalendar//EN
    VERSION:2.0
    BEGIN:VTIMEZONE
    TZID:Europe/Berlin
    X-LIC-LOCATION:Europe/Berlin
    BEGIN:DAYLIGHT
    TZOFFSETFROM:+0100
    TZOFFSETTO:+0200
    TZNAME:CEST
    DTSTART:19700329T020000
    RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
    END:DAYLIGHT
    BEGIN:STANDARD
    TZOFFSETFROM:+0200
    TZOFFSETTO:+0100
    TZNAME:CET
    DTSTART:19701025T030000
    RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
    END:STANDARD
    END:VTIMEZONE
    BEGIN:VEVENT
    DTSTART;TZID=Europe/Berlin:20150311T190000
    SUMMARY:Test (dmfs)
    TRANSP:OPAQUE
    STATUS:CONFIRMED
    DTEND;TZID=Europe/Berlin:20150311T200000
    LAST-MODIFIED:20150310T160708Z
    DTSTAMP:20150310T160708Z
    CREATED:20150310T160708Z
    UID:6f1a1f1f-6ce0-4bea-8cce-7060ae830dc4
    CLASS:PUBLIC
    END:VEVENT
    END:VCALENDAR
    

    Thanks for your time.


  • developer

    Timezones need to be included in VEVENTs. Both DAVdroid and the other client do that.

    DAVdroid uses ical4j, which includes an own set of the Olson Timezone DB (see https://github.com/ical4j/ical4j/wiki/Timezones). These timezone definitions may be different from the system definitions or the definitions other clients may use.

    The ical4j (and thus DAVdroid) timezones include a time zone history (just have a look at the definition). That means if you move a DAVdroid-created event in Europe/Berlin to pre-1916, the correct local offset (+005328, local solar time offset of Berlin in those days) will be used while the event created by the other client will just stay in +0100.

    And yes, that may be useless, but it's correct and I don't see a reason to change it, especially because it's an ical4j thing. The only "solution" could be to use system time zone definitions, but I guess the ical4j author(s) had good reasons to include their own database, so we will probably stick with it.


  • developer

    I'm closing this now, but if there's anything to add, please feel free to do so.


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.