Use of the Olson database (Re: Basic rationale of the KEP #2 design)

Joon Radley joon at
Thu Mar 3 11:31:38 CET 2011

Hi Bernard,

On 03 Mar 2011, at 11:56 AM, Bernhard Reiter wrote:

> Am Mittwoch, 2. März 2011 18:17:14 schrieb Joon Radley:
>>> For us, the only big issue is to write a Olson Timezone to/from Outlook
>>> (Windows) Timezone since we cannot depend on the name of the timezone to
>>> translate to Windows, we have to resolve the timezone by looking for the
>>> time zone string from the Olsen database and then we need to translate
>>> the Olsen timezone information into Windows.  Also reverse the process.
>>>  I'm not sure if that we will be able to cover 100% of the different
>>> timezone data between the two different set of timezone data, but we can
>>> come close.
>> This is a MUST requirement. Since neither you or us can control this, no
>> Outlook Kolab client can be KEP2 compliant or get certified.
> Joon, my Outlook test showed that invitations with VTIMEZONE
> are handled by Outlook (2007). This seems to indicate that Outlook is able
> to deal with everything that VTIMEZONE could display. If it can be done by 
> invitations, it must be representable within the Outlook objects somewhere.
> If this is the case, I'd say it should be sufficient for our purposes.
> As for the Olson mapping database, KEP2 id=10864 says that we shall come up
> with a mapping for systems that do not have this database. Being compliant
> with this mapping would be enough for being compliant with KEP2.

My understanding special use case that is driving KEP2 is as follows:

When an appointment is create by a special user the time for that user remains the same regardless of change in daylight savings time. The rest of the users appointments in the UI must now reflect a time adjusted so that the special users can still have his/her meeting at the same time. Two problems with this:

1) The Outlook UI is immutable and can change at any time. So there is no way to enforce the change in Outlook without rewriting all the objects not in the same time zone as the special user, when the daylight savings settings changes for the user.
2) Since no one knows if Outlook is using the Olsons database in the back ground there is no guarantee that they will display the zone as expected by other clients. This can be hacked to a large degree but full compatibility is not possible. 

So yes on the model side it is possible to try and translate between the Windows and Olsons zone, but the use case mention cannot be enforced in the Outlook UI without extreme measures.

Best Regards

Joon Radley

Cell: +27 (0)83 368 8557
Fax: +27 (0)86 547 2353
E-mail: support at

More information about the format mailing list