timezones, question of
Till Adam
till at kdab.net
Wed Feb 4 21:04:57 CET 2009
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>
More information about the format
mailing list