timezones, question of

[Till Adam]

Folks,

while implementing support for native timezones on Windows in Kontact, I've 
come across the fact that the spec (2.0rc7) specifies that all times shall be 
UTC, without timezone information. Now, this is clearly a simple and 
interoperable choice, and it works fine, so far. It does lead to a bit of lost 
information, in some use cases, though, some of which happen to be used by me, 
which got me thinking. 

If, for example, I make an appointment "at 10 a.m. in Chicago", I very much 
like the fact that Kontact (in 4.x) lets me specify a timezone along with the 
meeting time, and then shows me that meeting relative to my current timezone 
correctly. Once I've arrived in Chicago and change my timezone, the meeting is 
again in the right place. When I select it, it shows the date and time along 
with the timezone. That works great, as long as I use one of the other 
backends, namely ics files, and not the Kolab backend. In the Kolab backend I 
can still select the timezone when creating the event, but that timezone is 
not explicitly saved with the event. Instead, it is converted to UTC on write. 
The next time I open Kontact and the event is read, it shows in the right 
place, but tells me it's an event in UTC, which I can now no longer map to a 
place. Yes, there is a location in the event, and I'll likely know anyhow, 
from what the event is, but still, information has been lost that I find 
convenient to have around.

Assuming we actually wanted to solve this, and I'm not fully convinced we 
should, we'd run into the interoperability problem of how to encode the time 
zone information. RFC 2445 uses TZID, referencing the Olson timezone database, 
but that isn't used in Windows, for example. ICAL solves this by allowing any 
timezone id to be used and the description of that timezone to be shipped 
along with the even as a VTIMEZONE component. That can then be reconstructed 
on the other side. We could do the same in the Kolab format. Alternatively we 
could standardize on the Olson format and map on read, on Windows. That'd be a 
bother at least for Kontact on Windows, but I imagine also for the Outlook 
connectors.

So I see three options, which I'd like your feedback on, dear interested 
public:

1) leave things as is, and don't bother

2) implement the ical approach of a timezone description that is shipped along

3) come up with a standard timezone id format and map to local/native 
representations on the client

Thanks for taking the time to read this and parse it,

Till

-- 
Till Adam
KDAB - platform independent software services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20090204/8f7ec126/attachment.html>