Version: unspecified (using Devel)
OS: Windows CE
version: 2011-01-12 git-b984b66 w. old akonadi agent server
Steps to Reproduce:
Start the Calendar
Create a new event with an attendee
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.
TZID shouldn't be used.
Can you attach a ics file of such an event, please?
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.
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.
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.
PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN
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.
M +5 -0 kcalcore/icalformat_p.cpp
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.
3.2.19. Time Zone Identifier
Parameter Name: TZID
individual "VTIMEZONE" calendar component MUST be specified for
each unique "TZID" parameter value specified in the iCalendar
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.
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,
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.
M +29 -4 kcalcore/icalformat.cpp
M +2 -7 kcalcore/icalformat_p.cpp
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
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:
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
Outlook 2003 mainstream support ended 2009, extended support until Aug 2014
Outlook 2007 mainstream support until April 2012, extended s until April 2017
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.
Should send invitations in UTC for non-recurring events.
What should we do for recurring events ?!
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.
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
M +60 -0 kcalcore/icaltimezones.cpp