Basic rationale of the KEP #2 design

Georg C. F. Greve greve at
Thu Mar 3 11:28:44 CET 2011

On Wednesday 02 March 2011 17.51:04 Shawn Walker wrote:
> 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.

Assuming that both sets are complete, and assuming that the world is the same 
for both sets, mapping one geographical location to the other is possible. The 
only alternative would be to allow both tables, but that would complicate the 
issue further. 

Because all clients would need this table in order to be able to deal with 
invitations properly, the KEP also specifies that Kolab System will work on, 
maintain and continue to provide this mapping table in collaboration with all 
client providers.

The problem is that besides everything else, we want to make sure user time 
zone selections remain stored. Because we have no control over Outlook, we 
cannot let Outlook display what a Kontact client stored, so there will have to 
be translation in any case, even if we had chosen static encoding, as some 
people suggested.

It's a complexity incurred from the fundamental design and multi-platform 
approach, which we need to mitigate somehow, and one authoritative table for 
all clients still seems the easiest solution to this issue.

Best regards,

Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at
t: +41 78 904 43 33

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the format mailing list