DAVdroid can't handle events prior 1950



  • Thanks again for replying so quickly. As stated above, if aCalDAV and Thunderbird/Lightning can handle these events, I would assume that it’s not a problem with the calendar provider. That makes just no sense to me.

    I understand perfecly well that you can’t help on a problem which you can’t reproduce. Is there any additional information that could help? Anything I could try instead? Any idea where the problem could be?

    Edit: judging from your information on how the data is handled, I would then assume the problem is how DAVdroid converts the data for the Android calendar provider.


  • developer

    @flosch said in DAVdroid can't handle events prior 1950:

    I understand perfecly well that you can’t help on a problem which you can’t reproduce. Is there any additional information that could help? Anything I could try instead? Any idea where the problem could be?

    It would be necessary to reproduce the problem. Which device do you have? I suggest to post the debug info, as described in https://forums.bitfire.at/topic/749/read-before-posting-what-s-required-to-diagnose-a-problem/ It contains very important data like the device model and Android version, which is the reason why its should really be provided together with every problem report or question.

    Edit: judging from your information on how the data is handled, I would then assume the problem is how DAVdroid converts the data for the Android calendar provider.

    Why? I have posted the data which is generated by DAVdroid and it seems to be correct:

    • dtstart=-610761600000: UNIX time -610761600 is Fri Aug 25 00:00:00 1950 UTC ✓
    • duration=P1D seems to be OK for an all-day event ✓
    • rrule=FREQ=YEARLY;WKST=MO directly taken from the VEVENT ✓


  • @rfc2822 said in DAVdroid can't handle events prior 1950:

    Why? I have posted the data which is generated by DAVdroid and it seems to be correct:

    Sorry I was unclear about that. I didn’t doubt the validity of the data itself DAVdroid generates. Deducing from your information, the Android calendar provider handles events due to how either DAVdroid or aCalDAV or whatever DAV-sync-app provide the information. Since events processed by aCalDAV are handled correctly whereas the very same events handled by DAVdroid aren’t, that’s why I doubt the Android calendar provider to be the problem here. It could be, though, that both the calendar provider and aCalDAV stick to some non-standard protocol to transfer information whereas DAVdroid sticks to standard protocols the calender provider unfortunately doesn’t understand. But still, the events get rendered correctly between aCalDAV and the Android calendar provider which, by logic, exclude both from being the problem. Am I wrong? [mebeingconfused]

    I will provide the required debug information as soon as possible. Meanwhile: using Android 5.0.2, Calendar 4.40.17, DAVdroid 1.7.1-ose and aCalDAV 0.1.1.



  • Please find here the Debug info of DAVdroid. Just tried connecting to the CalDAV server via the internal LAN address instead of the internet which makes things even worse: now DAVdroid was unable to render the 1950 event as well. Randomly tried 1970 and it won’t show either. Only very recent events worked—very mysterious.


  • developer

    @flosch Then it seems quite clear to me: the server doesn’t send the event in the reply for the REPORT calendar-query of DAVdroid, which only requests event for 90 days into the past (+ forever in the future). The server has to calculate start and end date of recurring events and report them accordingly.

    It also explains why the events show up in aCalDAV and Thunderbird: those probably don’t use REPORT calendar-query, but other methods like a worse-performing general PROPFIND instead (where the server doesn’t do any filtering).

    To be sure please try to set the “Limit sync to X days in the past” setting in the DAVdroid account and leave the setting blank (default value: 90 days). Then sync again. If the event appears then, it’s clearly a server bug. By the way, which server do you use? This is a very important piece of information (as mentioned on https://forums.bitfire.at/topic/749/read-before-posting-what-s-required-to-diagnose-a-problem).



  • Colour me impressed! Leaving “Limit sync to X days in the past” blank really did the trick. To be honest, I doubted that solution because addressing the server via the internet (dyndns equivalent) instead of the home network, events past 1950 and not only the very recent showed up. And 1950 clearly is more than 90 days in the past! How come this is interpreted differently if either I address the server via the internet or via the internal LAN? The server is a Synology WebDAV, Version 2.3.3-0024, by the way. I wouldn’t expect much from filing a bug, however, since Synology is really slow, if caring at all.

    As yet I was just testing DAVdroid. Hence the free version. Now that everything seems to work, I will move to the non-free version to support development. Thanks again for your help, well done.

    Edit: is there a way to mark this solved?


  • developer

    @flosch I have set it to solved. Please report the bug to Synology nevertheless and provide the synology ticket ID for reference here, if possible, so we can mention it when someone encounters this problem in the future again.



  • I shall consider it. Two more questions off-topic:

    • do the free version 1.7.1-ose and the non-free version 1.7.1 of DAVdroid differ? If not, I will stick to the ose version and donate instead.
    • bying the app over amazon is EUR 3.19; how much do you (the DAVdroid developer(s)) get and what is Amazon’s share? Because the latter would be an additional reason for me to not buy the app but instead stick to the ose version and donate.


  • @flosch There is no difference in features (only a donation dialogue on startup)! The shops always take 30%. So in any case we prefer donations 🙂 Thanks in advance!



  • Thanks for the clarification. It’ll be a donation, then!



Similar topics