Bug 263018

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