View Single Post
Posts: 30 | Thanked: 89 times | Joined on Jan 2009
#156
I think I found a bug. Well it's not clear if this bug is with qalendar, nokia or anyone/anything else but something is odd:

I have an event, created ages ago, that repeats every week at a specific time. I'm syncing my N900 calendar via syncevolution (CalDAV) with an ownCloud instance. I'm syncing that with some other software (eM Client, also CalDAV). In eM Client this event is shown one hour off during summer... This is not how I wanted it. On my N900 it's fine.

I started investigating and found this:

When I export the whole calendar via qalendar that event does not have any time zone information. If I understand the RFC regarding time zone identifiers correctly this is not allowed unless you want it to be a "floating time" event. I quote:
This parameter [TZID] MUST be specified on the "DTSTART", "DTEND", "DUE", "EXDATE", and "RDATE" properties when either a DATE-TIME or TIME value type is specified and when the value is neither a UTC or a "floating" time.
Even more clearly:
The use of local time in a DATE-TIME value without the "TZID" property parameter is to be interpreted as floating time, regardless of the existence of "VTIMEZONE" calendar components in the iCalendar object.
I do not know how the calendar DB of N900 works but as you (the glorious and gracious creator of qualendar - I can't thank you often enough for creating this wonderful piece of software) stated before it is possible to set time zones and you implemented it and it seems to work fine. So I think there are at least two possibilities:
  1. Nokia didn't care about time zones and so if not explicitly set a calendar entry does not have a time zone. The export is "correct", but in stock calendar and qalendar it is interpreted "wrongly" (but consistent) as it should be a "floating time" event.
  2. All calendar entries do have a time zone but the export does not correctly handle that. I don't know exactly where syncevolution gets its data from but this has to be as broken as the stock calendar/qalendar export is possibly broken. Or is it all the same because all use the calendar backend?
I guess it's possibility no. 2 because in the exported calendar before each BEGIN:VEVENT is a BEGIN...END:VTIMEZONE. The only problem is that the timezone is not used within the VEVENT.

It seems somehow the export has to be fixed.

Did I misunderstand anything? Or is there an error in reasoning?

Edit: I wanted to create an example file but I somehow failed. The attached file can be imported to e.g. eM Client. (Rename to .ics!) It shows the behavior of a "floating time" event: It occurs on a different time when DST is active/inactive. Unfortunately I can't import that file with qualendar. It just says "An error occured".
Attached Files
File Type: txt testneu.txt (214 Bytes, 98 views)

Last edited by deryo; 2014-10-17 at 15:04. Reason: Added a file
 

The Following 4 Users Say Thank You to deryo For This Useful Post: