Created events have wrong time in other clients

0

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?

0

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.

Temporal relations are not necessarily causal relations.

0

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.

0

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?

Temporal relations are not necessarily causal relations.

0

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.

0

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.

0

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?

Temporal relations are not necessarily causal relations.

0

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.

0

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 πŸ™‚

Temporal relations are not necessarily causal relations.

0

@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.

0

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

Temporal relations are not necessarily causal relations.

0

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

0

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.

Temporal relations are not necessarily causal relations.

1

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.