Created events have wrong time in other clients



  • I'm using DAVdroid 1.0.5. on Android 5.1
    I'm creating a calendar entry at 9:00 a.m.
    Syncing with other devices, they show 10:00 a.m.

    The other way around:
    A calendar entry created on an other device (with Lightning or other) is (after syncing) correctly shown at 9:00 a.m on my device. but if I'm editing this entry on my device it shows 7:00 a.m.

    I've got no idea what to do.

    I would like to post the log, but: where is it stored?


  • developer

    Hello,

    PLEASE READ BEFORE POSTING: What's required to diagnose a problem. Everything's explained there.

    I have moved your posting to a new thread because it was not related to the other one.



  • Okay, once again, sorry for my impatience.

    Problem

    I'm creating a calendar entry "Nine" at 9:00 a.m. On my mobile phone everything is okay.
    Syncing with other devices works, but they show 10:00 a.m (one hour too late).

    The other way around:
    A calendar entry created on an other device (with Lightning or other) is (after syncing) correctly shown at 9:00 a.m on my mobile phone, but if I'm editing this entry it shows 7:00 a.m. (two hours - why not one hour, that would make at least a bit sense for me.)

    I've got no idea what to do. My system-clock is okay on all devices.

    Some more information

    Using DAVdroid 1.0.5 on Android 5.1.
    Here is all my debug info: http://ur1.ca/orgxc (I deleted one account.)
    Here is the log-File: http://ur1.ca/orgzw
    It works without problems with old versions of DAVdroid, that's why I'm thinking that it's not a server problem.


  • developer

    According at your logs, the event 03f90a73-b3b7-4958-8ef1-31cb7cec5522.ics is sent to the server with these data:

    BEGIN:VCALENDAR
    VERSION:2.0
    PRODID:+//IDN bitfire.at//DAVdroid/1.0.5 ical4android ical4j/2.x
    BEGIN:VEVENT
    DTSTAMP:20160405T202946Z
    UID:03f90a73-b3b7-4958-8ef1-31cb7cec5522
    DTSTART;TZID=Europe/Berlin:20160406T090000
    DTEND;TZID=Europe/Berlin:20160406T100000
    SUMMARY:Nine
    STATUS:CONFIRMED
    END:VEVENT
    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
    END:VCALENDAR
    

    Assuming that the VTIMEZONE is correct (theoretically, it may be wrong; however, timezone definitions haven't changed in DAVdroid recently), this is the correct time:

    DTSTART;TZID=Europe/Berlin:20160406T090000
    

    So I can't see any error.

    Is it possible that you're editing/viewing the events in different time zones? Can you check if all your clients (the "other devices") are set to the same time zone?



  • I didn't know, that this is the server. The mail-account is hosted by a service called belwue.
    I just tried with an other mail-account: successfully.
    So it's a problem of the server you mentioned, right? I'll contact belwue.



  • I contacted belwue but they can't help me. They say that everything is fine with syncing between them and thunderbird for example - what's right. :-(
    Strange: Everything is good with my private calendar (webmail, thunderbird, DAVdroid/aCalendar), with my job calendar webmail to thunderbird works but not to and from DAVdroid/aCalendar.


  • developer

    Is it possible that you're editing/viewing the events in different time zones? Can you check if all your clients (the "other devices") are set to the same time zone?



  • May be I don't understand you. In the app aCalendar I've got an option for time zone but variations doesn't change the effect above. I think that my editing/viewing is not in different time zones because I've got the same date with my private calendar.


  • developer

    I see.

    I contacted belwue but they can't help me. They say that everything is fine with syncing between them and thunderbird for example - what's right. :-(

    I don't understand how Thunderbird is related to the problem that an uploaded .ics doesn't have the correct time… but I don't have to understand everything :)



  • @rfc2822 Thunderbird with lightning is the program I use for calendars on my linux-client. I think it doesn't cause a problem... I don't want to understand everything, too, but I like things working.


  • developer

    @publicfriend Can you maybe provide a test account which would allow us to reproduce the problem?



  • @rfc2822 Yes, now I can. I've send you the data via chat.


  • developer

    When you PUT this iCalendar (event at 10:00 Amsterdam) to the server:

    BEGIN:VCALENDAR
    VERSION:2.0
    PRODID:+//IDN bitfire.at//DAVdroid/1.0.7 ical4android ical4j/2.x
    BEGIN:VEVENT
    DTSTAMP:20160419T181249Z
    UID:717818d8-edba-45e2-bd2a-78292fa86113
    DTSTART;TZID=Europe/Amsterdam:20160420T100000
    DTEND;TZID=Europe/Amsterdam:20160420T110000
    SUMMARY:10Berlin
    STATUS:TENTATIVE
    END:VEVENT
    BEGIN:VTIMEZONE
    TZID:Europe/Amsterdam
    TZURL:http://tzurl.org/zoneinfo/Europe/Amsterdam
    X-LIC-LOCATION:Europe/Amsterdam
    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:+001932
    TZOFFSETTO:+001932
    TZNAME:AMT
    DTSTART:18350101T000000
    RDATE:18350101T000000
    END:STANDARD
    BEGIN:DAYLIGHT
    TZOFFSETFROM:+001932
    TZOFFSETTO:+011932
    TZNAME:NST
    DTSTART:19160501T000000
    RDATE:19160501T000000
    RDATE:19170416T030000
    RDATE:19180401T020000
    RDATE:19190407T020000
    RDATE:19200405T030000
    RDATE:19210404T020000
    RDATE:19220326T020000
    RDATE:19230601T020000
    RDATE:19240330T020000
    RDATE:19250605T020000
    RDATE:19260515T020000
    RDATE:19270515T020000
    RDATE:19280515T020000
    RDATE:19290515T020000
    RDATE:19300515T020000
    RDATE:19310515T020000
    RDATE:19320522T020000
    RDATE:19330515T020000
    RDATE:19340515T020000
    RDATE:19350515T020000
    RDATE:19360515T020000
    RDATE:19370522T020000
    END:DAYLIGHT
    BEGIN:STANDARD
    TZOFFSETFROM:+011932
    TZOFFSETTO:+001932
    TZNAME:AMT
    DTSTART:19161001T000000
    RDATE:19161001T000000
    RDATE:19170917T030000
    RDATE:19180930T030000
    RDATE:19190929T030000
    RDATE:19200927T030000
    RDATE:19210926T030000
    RDATE:19221008T030000
    RDATE:19231007T030000
    RDATE:19241005T030000
    RDATE:19251004T030000
    RDATE:19261003T030000
    RDATE:19271002T030000
    RDATE:19281007T030000
    RDATE:19291006T030000
    RDATE:19301005T030000
    RDATE:19311004T030000
    RDATE:19321002T030000
    RDATE:19331008T030000
    RDATE:19341007T030000
    RDATE:19351006T030000
    RDATE:19361004T030000
    END:STANDARD
    BEGIN:DAYLIGHT
    TZOFFSETFROM:+011932
    TZOFFSETTO:+0120
    TZNAME:NEST
    DTSTART:19370701T000000
    RDATE:19370701T000000
    END:DAYLIGHT
    BEGIN:STANDARD
    TZOFFSETFROM:+0120
    TZOFFSETTO:+0020
    TZNAME:NET
    DTSTART:19371003T030000
    RDATE:19371003T030000
    RDATE:19381002T030000
    RDATE:19391008T030000
    END:STANDARD
    BEGIN:DAYLIGHT
    TZOFFSETFROM:+0020
    TZOFFSETTO:+0120
    TZNAME:NEST
    DTSTART:19380515T020000
    RDATE:19380515T020000
    RDATE:19390515T020000
    END:DAYLIGHT
    BEGIN:DAYLIGHT
    TZOFFSETFROM:+0020
    TZOFFSETTO:+0200
    TZNAME:CEST
    DTSTART:19400516T000000
    RDATE:19400516T000000
    END:DAYLIGHT
    BEGIN:STANDARD
    TZOFFSETFROM:+0200
    TZOFFSETTO:+0100
    TZNAME:CET
    DTSTART:19421102T030000
    RDATE:19421102T030000
    RDATE:19431004T030000
    RDATE:19441002T030000
    RDATE:19450916T030000
    RDATE:19770925T030000
    RDATE:19781001T030000
    RDATE:19790930T030000
    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:+0100
    TZOFFSETTO:+0200
    TZNAME:CEST
    DTSTART:19430329T030000
    RDATE:19430329T030000
    RDATE:19440403T030000
    RDATE:19450402T030000
    RDATE:19770403T020000
    RDATE:19780402T020000
    RDATE:19790401T020000
    RDATE:19800406T020000
    END:DAYLIGHT
    BEGIN:STANDARD
    TZOFFSETFROM:+0100
    TZOFFSETTO:+0100
    TZNAME:CET
    DTSTART:19770101T000000
    RDATE:19770101T000000
    END:STANDARD
    END:VTIMEZONE
    END:VCALENDAR
    

    and then immediately GET it, the server will return

    BEGIN:VCALENDAR
    PRODID:CommuniGate Pro 6.1.8
    VERSION:2.0
    BEGIN:VEVENT
    DTSTAMP:20160419T184305Z
    UID:717818d8-edba-45e2-bd2a-78292fa86113
    SEQUENCE:0
    SUMMARY:10Berlin
    DTSTART:20160420T090000Z
    DTEND:20160420T100000Z
    X-MICROSOFT-CDO-BUSYSTATUS:BUSY
    LAST-MODIFIED:20160419T184303Z
    CREATED:20160419T184303Z
    PRIORITY:5
    STATUS:TENTATIVE
    END:VEVENT
    END:VCALENDAR
    

    As you can see, the server has rewritten the event (that's OK with CalDAV). But it has rewritten the event to 09:00 UTC, which is 11:00 Amsterdam. (This is the problem.)

    I can imagine two causes for the problem:

    1. The Amsterdam VTIMEZONE sent by DAVdroid is incorrect. DAVdroid uses the ical4j timezone definitions, which are regularly updated from the Olson DB. Also, I can't see anything wrong with the VTIMEZONE, so I don't think that's the problem.
    2. Your server tries to parse the VTIMEZONE, but fails for some reason and "adds" an additional hour.

    If you remove the "unnecessary" parts of the VTIMEZONE for < 1996 and PUT it to the server:

    BEGIN:VCALENDAR
    VERSION:2.0
    PRODID:+//IDN bitfire.at//DAVdroid/1.0.7 ical4android ical4j/2.x
    BEGIN:VEVENT
    DTSTAMP:20160419T181249Z
    UID:717818d8-edba-45e2-bd2a-78292fa86113
    DTSTART;TZID=Europe/Amsterdam:20160420T100000
    DTEND;TZID=Europe/Amsterdam:20160420T110000
    SUMMARY:10Berlin
    STATUS:TENTATIVE
    END:VEVENT
    BEGIN:VTIMEZONE
    TZID:Europe/Amsterdam
    TZURL:http://tzurl.org/zoneinfo/Europe/Amsterdam
    X-LIC-LOCATION:Europe/Amsterdam
    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:19961027T030000FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
    END:STANDARD
    END:VTIMEZONE
    END:VCALENDAR
    

    the server will rewrite it correctly to 08:00 UTC = 10:00 Amsterdam:

    BEGIN:VCALENDAR
    PRODID:CommuniGate Pro 6.1.8
    VERSION:2.0
    BEGIN:VEVENT
    DTSTAMP:20160419T184831Z
    UID:717818d8-edba-45e2-bd2a-78292fa86113
    SEQUENCE:0
    SUMMARY:10Berlin
    DTSTART:20160420T080000Z
    DTEND:20160420T090000Z
    X-MICROSOFT-CDO-BUSYSTATUS:BUSY
    LAST-MODIFIED:20160419T184829Z
    CREATED:20160419T184829Z
    PRIORITY:5
    STATUS:TENTATIVE
    END:VEVENT
    END:VCALENDAR
    

    So unless the VTIMEZONE is incorrect (and I really doubt that, because when I just remove the old DAYLIGHT/STANDARD components and leave the most recent one, everything works; and the old ones should be ignored for an event in 2016 anyway), your problem is caused by your server which parses the VTIMEZONE incorrectly and then rewrites the event to the wrong time.



  • Long ago since rfc2822 worked on this problem with a person of the mentioned service.
    I just want to write, that the problem is solved and every time is showed correctly.
    Thank you a lot for this!



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