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!
Moscow time zone
The next DAVdroid release will contain ical4 with the tzdata2015c time zones. However,
- as far as I can see, the last update for Moscow is from 2011 even in the tzdata2015c database,
- the system time zones (and thus the ones in your calendar app) are not affected by this, meaning that imported events should have the correct time as far as DAVdroid is involved in calculating, but the system and calendar apps will still use the old time zone definitions. This can only be fixed by a firmware update.
Thanks! Waiting for release.
- MSK timezone has been changed with 2014h release.
- On old firmwares system timezone can be changed to the zone with the correct time (for current MSK it’s +3), so the offset between ICS time data and system time disappears. It’s a workaround. Opposite to this, there is no way to view and create events with the correct time simultaneously (using an old ical4j tzdata). Еvents created using software with an up-to-date timezone data (and correct timezone set) are displayed wrong with an old ical4j tzdata, until you set your system timezone to another value to remove an offset. But if you set so, new events created on this system will be displayed wrong on other systems/software. The only way to fix this was repacking DAVdroid with an updated tzdata. But now, 0.8.2 is coming
Is this the correct & up-to-date definition? I can see 2014 somewhere but I don’t know… it should be from 2015c
Yes, it’s correct. At RDATE:20141026T020000 the time was moved from +4 to +3 and that’s the current timezone.
Ok thanks. Unfortunately, I didn’t manage the self-compiled ical4j to get working (see https://github.com/ical4j/ical4j/issues/29), so we’ll have to wait for the next ical4j release (maybe with DAVdroid 0.8.3).
It seems that the bug is still present in DAVdroid 0.9.1.2. Have there been any updates? It’s been over a year since the Moscow timezone has changed, and synchronization from ownCloud running on a fully updated Debian via DAVdroid is still broken. The ownCloud’s web interface displays all events correctly.
@rfc2822 I’m not sure since this is the first time I see the internals of an
.icsfile, but the only entry with a mention of 2014 is https://github.com/ical4j/ical4j/blob/764878f4fc8eaf311a6274b50ab2d1e70da84d23/src/main/resources/zoneinfo/Europe/Moscow.ics#L100. The current MSK timezone is UTC+3 without daylight saving time (https://www.timeanddate.com/worldclock/russia/moscow). According to http://stackoverflow.com/a/3872214/1214547,
TZOFFSETFROMis the offset with DST and
TZOFFSETTOis the offset without DST. The definitions in
So it looks like the definitions are incorrect. Could you check that?
@Pastafarianist Which timezone definitions are we speaking about? Each .ics has its own TZ definition, and they will not be updated by the nature of iCalendar/CalDAV.
When you have created an event with the old time zones for some time (let’s say 13:00 local time = 15:00 UTC), and then the local time zone changes +1 hour, the event will not be magically moved +1 hour. Every event gets the time zone of the time of creation.
Maybe we’re not talking about a bug, but well-defined CalDAV behavior.
Please provide detailed steps to reproduce your problem (including questionable .ics files and DAVdroid versions).
I was talking only about the contents of a particular file in ical4j repo. It looked like it contained incorrect timezone definitions. However, right now I can’t reproduce the problem I mentioned. An event created either on the server or on the client syncs to the other party with the correct timezone in both ways.
I vaguely recall that earlier after wiping calendar storage the events would be synced with incorrect timezones, so I’ve just tested it. Unlike Google calendar, the events synced by DAVDroid were not repopulated, but after I deleted and re-added the account everything was back in place, including the proper timezones.
I guess this particular issue is resolved.