Version: unspecified (using Devel) OS: Windows CE version: 2011-01-12 git-b984b66 w. old akonadi agent server Reproducible: Always Steps to Reproduce: Start the Calendar Create a new event with an attendee Actual Results: The start and end time of the event contains the TZID attribute (timezone identity) Kontact enterprise35 doen't understand this and displays the event at a wrong time. Expected Results: TZID shouldn't be used.
Hej Ludwig, Can you attach a ics file of such an event, please? Ciao, Tobias
No, I cannot. At the moment I'm not able to send an invitation. If I try I get an error msg.
Created attachment 56185 [details] A cal.ics of an invitation sent from Calendar touch After a restart of the mobile sending invitation worked. Here is the cal.ics part of invitation. See DTSTART.
Which timezone did you choose in the event editor? Can you reproduce on the desktop?
Sergio, we do not have current versions of the desktop ready. AFAIK there is not timezone that you could select in the Kontact Touch Composer or its options.
The definition of the timezone seems to be missing. BEGIN:VTIMEZONE TZID:Mitteleurop. Standardzeit END:VTIMEZONE I also believe that it is easier to use UTC for non-recurring invitations. (There is no significant drawback I can think off. The only minor drawback is that the recipient does not now about which timezone the organizer was thinking, but I blieve that is neglectable.)
We now use olson timezone names which are recognized and leave the vtimezone element out. Tested that e3.5 shows the correct time now.
Does the VTIMEZONE specification allow for Olson names? Does this work with Outlook? We cannot close this issue unless interoperability with Outlook has been tested.
Ludwig, please test this change against outlook. Thanks!
This is what the invitation looks like now: Resulting in enteprise 3.5 showing old dates. BEGIN:VCALENDAR PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Berlin END:VTIMEZONE BEGIN:VEVENT CREATED:20110207T101632Z ORGANIZER;CN="Komotest1":MAILTO:komotest1@demo.kolab.org ATTENDEE;CN="Komotest1";RSVP=FALSE;PARTSTAT=ACCEPTED;ROLE=REQ-PARTICIPANT; X-UID=1787404688:mailto:komotest1@demo.kolab.org ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto: aheinecke@intevation.de DTSTAMP:20110207T101411Z UID:libkcal-13596.36 LAST-MODIFIED:20110207T101411Z SUMMARY:11.14 DTSTART;TZID=Europe/Berlin:20110207T111400 DTEND;TZID=Europe/Berlin:20110207T131400 TRANSP:OPAQUE END:VEVENT END:VCALENDAR
In the last message i have written "Enterprise 3.5 shows old dates" What i meant to say was that enterprise 3.5 shows the wrong time. One hour after the Appointment should take place.
Git commit 8bfa7681f91461ade1b5606f7ca300dd3c4f64d3 by Tobias Koenig. Committed on 08/02/11 at 11:21. Pushed by tokoe into branch 'komo3'. Exclude VTIMEZONE from invitations on WinCE Since WinCE does not support creating proper VTIMEZONE elements, we omit them and trust on the standard names from Olson database. BUG: 263018 M +5 -0 kcalcore/icalformat_p.cpp http://commits.kde.org/kdepimlibs/8bfa7681f91461ade1b5606f7ca300dd3c4f64d3
Tobias: Is it okay from the standard to use TZID without VTIMEZONE? Note that we must be Outlook compatible and as far as I know Outlook does not have an Olson database coming with it. Using UTC without TZID (especially for single occurances) seems to have a higher chance to be Outlook compatible. Ludwig@ Please do an outlook test.
http://www.rfc-editor.org/rfc/rfc5545.txt: 3.2.19. Time Zone Identifier Parameter Name: TZID [..] An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object. windows-ce/Kontact-Mobile/testing/2011-02-10-21-10 has a TZID id, but not VTIMEZONE definition. So it violates the standard Outlook 2003 SP3 on Windows XP (both German) thus does not recognise the timezone and display the appointment at the wrong time.
Interesting enough: Outlook 2007 (12.0.6423.1000) SP2 MSO (12.0.6425.1000) on Windows Vista (both German) did correctly display an appointment with no VTIMEZONE, but: DTSTART;TZID=Europe/Berlin:20110211T155900 DTEND;TZID=Europe/Berlin:20110211T175900 So the behavior is different for OL 2003 and OL 2007. :/ The behaviour seems not matching the standard: http://www.rfc-editor.org/rfc/rfc5545.txt, which has a possiblity for a global TZ databse in the future but indicated with a leading '/'
Git commit 7f2d63468e3b097d21756d3440b6062b11da96b6 by Tobias Koenig. Committed on 14/02/2011 at 17:11. Pushed by tokoe into branch 'komo3'. Use UTC times for non-recurring invitation times Since KDE 3.5 and Outlook do not handle the TZID attribute in invitation mails correctly, we restore compatibility by always using UTC times for non-recurring events. In case of recurring events we provide the TZID information, because that is needed to schedule events in different timezones with different DST correctly. BUG: 263018 M +29 -4 kcalcore/icalformat.cpp M +2 -7 kcalcore/icalformat_p.cpp http://commits.kde.org/kdepimlibs/7f2d63468e3b097d21756d3440b6062b11da96b6
@Tokoe: We did _not_ establish that Kontact Desktop e35 or Outlook is not correct. Uncorrect is the behaviour of Kontact Touch to use a TZID which is not defined properly as VTIMEZONE. (See my comment #14.) Re Comment #15: I have to correct myself about Outlook 2007 behaviour: My test was not conclusive, as floating time and correct time were the same. It could be that Outlook 2007 correctly interpets the TZID without VTIMEZONE as floating time. Note that as far as I have understood Kontact Touch on MS CE cannot create VTIMEZONE entries. If this is the case only Kontact Touch on CE must use UTC and we still have to decide about what other versions should do. If Outlook behaviour with TZID and VTIMEZONE is correct, then all versions of Kontact (that can) should create it, I'd say. According to #16 Kontact Touch still does not use UTC for recurrences. If so, code should be changed IMO to use UTC for recurrances on CE only. [o] Correct behaviour in this comment means according to (my interpretation) of http://www.rfc-editor.org/rfc/rfc5545.txt(correctly according to RFC
Added a testscript for this here: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/utils/testing/test-send-invitations-timezone.py Results: test1) invalid VCALENDER with TZID=Europe/Berlin, but missing the corresponding VTIMEZONE: OL 2003 cannot, it will display the event at the wrong time, assuming UTC without further notice. This ss a stricter rfc interpretation then OL 2007. OL 2007 can deal with it. Thus it interprets the name. (No idea how many names it knows, though.) test2 and test3) with TZID and good VTIMEZONE info (created by Kontact Touch N900 4:4.6~.20110211.1251.git9d81e94-1maemo1.1219908 carrige returns fixed manually) Both OL 2003 and OL 2007 can deal with it. One test included a repeated appointment accross one sometime change. test4) Repeating appointment in UTC (created by Kontact Touch CE being at the same time) OL 2003 will display and calculate it from the first appointment and adjust for the sommertime shift. So Kontact Touch and CE are displaying the same. OL 2007 will behave stricter towards the RFC and warn the user in the appointment that it repeats in GMT+0 having no timezone, displaying the GMT time! When accepting the appointments they are at the right time in UTC shown at two different times in Berlin/Europe. test5 test6) Both OL 2003 and OL 2007 can display single UTC events. Lifetime of tested Outlook versions (inquired at http://support.microsoft.com/gp/lifeselectindex, can be longer according to http://support.microsoft.com/gp/lifepolicy) Outlook 2003 mainstream support ended 2009, extended support until Aug 2014 Outlook 2007 mainstream support until April 2012, extended s until April 2017 Conclusion: To be compatible with both versions of Outlook tested for recurrent events, we would need to send a proper VTIMEZONE with use of the TZID. It is okay to send VTIMEZONE with the use of TZID for singe instance events.
So, WinCe: Should send invitations in UTC for non-recurring events. What should we do for recurring events ?! options: A) Use UTC B) Use TZID and no VTIMEZONE A) is bad because of the day light shift B) is bad because it breaks OL2003 and possibly more clients. Desktop: Should always use TZID and VTIMEZONE when sending invitations.
As discussed yesterday: On CE we also can send TZID + VTIMEZONE for the timezone we are currently in. Andre, can you make the change?
Git commit fb6883c61020535ae88e13e648dbdf5f362601e9 by Andre Heinecke. Committed on 04/03/2011 at 11:03. Pushed by aheinecke into branch 'komo3'. Write a valid VTIMEZONE on Windows CE On Systems that do not provide a valid database about Timezone transitions the VTIMEZONE entry of the ical data would only contain the Tzid. For WinCE there is now a fallback to write the current Timezone information in the entry. This works since the gui on WinCE does not offer the user to create an Event in a different Timezone. I've added the code here in kcalcore instead of KTimeZone because this is tailored specifically to what the ical format requires and can not be generalized to other timezones then the current Zone. BUG: 263018 M +60 -0 kcalcore/icaltimezones.cpp http://commits.kde.org/kdepimlibs/fb6883c61020535ae88e13e648dbdf5f362601e9