Calendar items in phone are synced then will change time



  • Versions

    • Zimbra 8.7.11
    • Android 7.1.1
    • DAVDroid 1.9.7-ose

    Symptoms

    • Events created from phone or from computer will sometimes display on the phone as being at 23:30(with no finish time).
    • In instances where a solo(not sent to anyone else) event is created by me on my phone, sometimes it will end up being moved to 23:30 the previous day.
    • They will always be the day before the actual event was created.
    • This happens on events owned by me or other zimbra users.
    • Moving one of these incorrectly synced events on the computer to another day will result in it being displayed on the phone at 23:30 the day prior.
    • Moving one of these incorrectly synced events on the phone to another day will result in the computer matching the 23:30 date as updated by the phone

    Notes

    • I've tested CalDAV connectivity on Thunderbird and this behaviour is not observed, so I suspect the issue is with something on the phone side instead of the server side.
    • Every device has it's time zone set correctly to Australia/Melbourne

    Logs

    • When I did a adb logcat I wasn't able to find anything that gave any clues or detail about the times of the test event being synced down by the phone.
    • Instead of me pasting an overload of log file noise, is there any specific logs or log levels you'd like me to retrieve and add to this post?

  • developer

    Hello,

    Can you provide a test account and specific steps to reproduce so that I can reproduce the problem? Please send it to play@bitfire.at (PGP 🔑).



  • thanks @rfc2822

    I just sent you some login details


  • developer

    @zstephen Thanks! Do you know specific steps to reproduce the problem, so that I can try without having to play around first? Does this happen only for some events?



  • @rfc2822 good question. Unfortunately this issue is intermittent. I just tried to reproduce it this morning and couldn't. But I also noticed the issue happened for an event I created on my phone a few days ago. The strange issue is that I know that before the issue existed and me discovering it, no versions of any software have changed, nor have any configs of my network. My testing has me thinking that the issue is phone related as other caldav clients don't produce this problem.

    I'll keep trying to identify what I can do to cause the issue.

    For what it's worth, I've been a user of Business Calendar 2 for years instead of the default Android offering. But it's always been a very robust program. Do you know otherwise? As far as my testing can show, Business Calendar 2 and Google Calendar are displaying the phone's calendar contents exactly the same. i.e. for the "erroneous previous day 23:00 event" they show as the same time. It's like something in the translation of the caldav payload is getting mixed up in between zimbra and the phone's local copy of an event.

    Is there any way I can verbosely see the calendar event details in logcat mode?

    I can try to pinpoint this log payload in my own calendar where I am seeing this issue by looking for that event name in the sync log files.

    Intermittent problems are the worst, I've always disliked them.


  • developer

    @zstephen said in Calendar items in phone are synced then will change time:

    Intermittent problems are the worst, I've always disliked them.

    That's true…

    Is there any way I can verbosely see the calendar event details in logcat mode?

    I can try to pinpoint this log payload in my own calendar where I am seeing this issue by looking for that event name in the sync log files.

    Yes, when you turn on DAVdroid logging, all synchronized events will be logged, including date/time/time zone and name, so you can then search for the names.

    I guess it maybe somehow related to the time zone… maybe it happens only for events when DST is (in)active or around the DST change?

    However, the best thing would be to turn on DAVdroid logging and leave it on until the problem occurs (will take some space). Then every required information should be in the logs.