KEP 2: Semantic update of draft for "Modification of datetime: store local time, add 'tz' attribute"

Bernhard Reiter bernhard at
Tue May 31 13:42:49 CEST 2011

Am Freitag, 20. Mai 2011 17:49:27 schrieb Bernhard Reiter:
> >
> >6
> >
> > and are encouraged to please give this a look and make sure nothing has
> > been overlooked.
> Thanks to Georg for writing this all up! I believe Florian, Georg and
> myself have come up with a good compromise KEP2 that addresses the
> problems, is standard compliant where possible and is implementable by all
> clients.
> If not, raise your voice. :)

Here is an exchange I had with Joon, after this semantic update.
Forwarded with Joon's permission. Note that the comments were written
before the last round of smaller changes. And Joon still wants to look
at my response in detail. So unless I have missrepresented something
I guess we should wait for Joon's reply.

My summary: I believe Toltec can implement the now-overhauled KEP2
with Toltec for Outlook 2003 and Outlook >=2007 .
And the  KEP2 wording supports this (of course wording can always be 


----------  Weitergeleitete Nachricht  ----------
Betreff: Re: KEP2
Datum: Montag, 23. Mai 2011
Von: Bernhard Reiter <bernhard at>

> > Which are the display requirements that you cannot fullfil?

Am Sonntag, 22. Mai 2011 06:49:57 schrieb Joon Radley:
> * When creating a new object with time zone sensitive fields, clients
> SHOULD default to the local time zone of the user, but SHOULD allow the
> user to select the time zone for storage and consequently recurrence
> calculation; - This would require a UI popup or selection field in Outlook.
> We can add a selection field in the toolbar and try and catch the object as
> it is read and save when a recurring event is edited, but not when it is
> created. Also this would require substantial modification to the existing
> code.

As you say: Outlook 2007 already has such a selection field.
As for Outlook 2003,  SHOULD means that is RECOMMENDED  (as in rfc 2119)
so you can deviate from the behaviour and you are still compliant with Outlook 
2003. I believe that Outlook 2003 constitutes such a "valid reason" (as per 
RFC 2119).

> * When modifying existing objects, clients MUST use the value of the 'tz'
> attribute of the respective fields to set the default/preselected value for
> the editing of the fields, where applicable. For instance the 'start-date'
> and 'end-date' time zone defaults if presented to the user by the client
> MUST match those stored in the 'tz' attribute. 

We have made sure by the "if presented" that Outlook 2003 can still 
implement this, because the "MUST" does not apply, because it is not 

> The time zone stored in the 
> 'tz' attribute SHOULDonly be changed based upon user interaction; - I
> provide the UTC time, Outlook calculates the local time. Since Outlook 2007
> there has been an option to control some of the zone calculation in some
> way, but this would not directly translate between Olson or even Windows
> time zone specifications. This would also mean that Outlook 2003 cannot be
> supported.

For Outlook 2007, it is okay to do the translation via the mapping table.
For Outlook 2003 you are fine because the field is not presented - only the 
calculation has to be correct, which it is, when the translation to the 
windows timezones is applied as sync time (reading or writing).

> *When calculating recurrences, a client MUST calculate in a way that keeps
> the event at the same local time in the time zone stored in the 'tz'
> attribute. Clients MUST then use the result as the time from which to
> calculate the time of the event at the client's time zone. For more detail
> see Notes for client implementors below); - Outlook does the calculation.
> Also the same reasons are the point above.

In my tests Outlook 2007 does this correctly when given the timezone,
as Outlook also aims for iTIP compliance. I believe Outlook 2003 also does is 

There might be a defect in Outlook 2003, but I am not sure. If it has a 
defect, it would also mean it is also defect for iTIP invitations. 
(All implementation will have defects, this still means Outlook 2003 can be a 
first class implementation.)

> *When receiving iTip invitations, a client MUST treat the time zone id in
> the VTIMEZONE object as authoritative and, if it is not a valid Olson
> database time zone identifier, translate it using the translation matrix
> provided by Kolab Systems in cooperation with the Kolab ecosystem. If the
> time zone id in the VTIMEZONE element does not exist in the matrix, clients
> MAY attempt to map the time zone based on its rules to a currently used
> time zone -- AND/OR -- allow the user to select an appropriate time zone
> for event storage; - iTip parsing and processing is done by the Outlook
> converter.

It is fine that Outlook parses and processes the invitations.
Only when you write or read the storage object, you apply the mapping.

There is a corner case when the mapping is missing in recurrance cases, but 
all clients have this issue.

> I cannot set long time fractions as shown in the "Kolab ISO8601 profile".

This is why there is no object required it.
This probably will only be required in the future on objects which need it
probably real-time-communication, so it wouldn't be of concern for Outlook 
anyway, unless it grew automated chat functions or so. :) Seriously: If there 
is going to be a dataobject of outlook that needs that precision in the 
future, it will also have the fraction of a second to be set internally.

> There is no official translation between Windows and Olson timezones. While
> trying to build this list via trail and error over time the internal
> timezone setting (That was converted at time of synchronization) will be
> broken. This would require a migration of all objects every time the
> mapping is updated.

I guess that we will find almost all of the mapping table quite soon,
but note that we also need this for the non-windows clients as they will have 
to deal with this when invitations from windows come in. So there is a good 
motivation to make that table complete and correct. And we can verify the 
table, once we have it to be correct for the entry we have. So once we map 
something, we will be okay for a while. 

You are correct in that there is a bit of an issue
when the mapping does not exist.
I believe this rare case can be dealt with in an acceptable way.
Possibly we warn the user at sync time and for single appointments try to 
calculate it in UTC, so no functionality is lost.

Hmm I get an idea, I wonder if we should require that Kolab client can only 
use "olson" ids where there is a mapping in the table. This way, a windows 
client would always be fine.

> > For which tag does it not make sense?
> > <start-date> and <end-date> are clearly in the future, so they suffer
> > from the mentioned problems.
> <start-date tz="ZoneA">
> <end-date tz="ZoneB">
> And every other user settable  date time field can have a different
> timezone. It can become very confusing very fast, especially when
> translating from and to multiple fields in Outlook.

You are refering to the fact that ZoneA and ZoneB can be different.
I haven't tried, but Outlook 2007 allows, this doesn't it?
We have found that some users really like this for flights,
though I am not sure how often it gets used in practice.
So I think your problem might be Outlook 2003 here, my approach would be to 
recalculate the end-date so it is correct and then give this to outlook.

Yes, I know, this is all a bit of work. On the other hand I am happy that we 
are trying to approach this an other issues now, like the subappointments.
It often got asked and we have to make the kolab storage format better here
sooner or later. 

I guess that older clients will be around for a while and newer clients keep a 
backwards compatibility mode until a full installation can be switched. I 
just hope that first implementation can start when the KEP2 is approved
and Toltec is among them. 

Managing Director - Owner:       (Free Software Company)
Deputy Coordinator Germany: Board member:
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the format mailing list