From till at kdab.net Wed Feb 4 21:04:57 2009 From: till at kdab.net (Till Adam) Date: Wed, 4 Feb 2009 21:04:57 +0100 Subject: timezones, question of Message-ID: <200902042104.59159.till@kdab.net> 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://kolab.org/pipermail/kolab-format/attachments/20090204/8f7ec126/attachment.html From helge.hess at opengroupware.org Wed Feb 4 23:02:57 2009 From: helge.hess at opengroupware.org (Helge Hess) Date: Wed, 4 Feb 2009 23:02:57 +0100 Subject: timezones, question of In-Reply-To: <200902042104.59159.till@kdab.net> References: <200902042104.59159.till@kdab.net> Message-ID: On 04.02.2009, at 21:04, Till Adam wrote: > 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. As a matter of fact preserving timezone information is a necessity for recurring events. You can't properly express calculated recurrences spanning DST changes w/o it. > RFC 2445 uses TZID, referencing the Olson timezone database Thats incorrect. A TZID always references a VTIMEZONE embedded in the iCalendar entity. It has nothing to do with Olson (Olson is just mentioned as one example which an implementor could use). > 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. Nitpicking, but iCal _requires_ that the timezone is shipped with the entity. And the client must parse that timezone and use it. Since VTIMEZONE objects can use arbitrary RRULEs to define the timezone, its quite a complex topic. Most interesting is what to do if the client can't express the timezone. (eg Outlook). > 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 BTW: as we speak there is a CalConnect event with a focus on timezones: http://www.calconnect.org/calconnect14.shtml Would be interesting to see what they come up with ... AFAIK an official timezone registry is in discussion. Greets, Helge From bernhard at intevation.de Thu Feb 5 10:36:21 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 5 Feb 2009 10:36:21 +0100 Subject: timezones, question of In-Reply-To: <200902042104.59159.till@kdab.net> References: <200902042104.59159.till@kdab.net> Message-ID: <200902051036.24665.bernhard@intevation.de> Till, On Mittwoch, 4. Februar 2009, Till Adam wrote: > 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. I believe Kontact should display the time in your local timezone, which works, because it knows which timezone you have set it to when looking at the event. > 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. As long as you have the time, I do not think it matters in which timezone you have created the appointment. Hm I guess I would need to understand the use case better. Probably you are using the timezone display for calculating the time for others, like uh, this will be local time 7am so it is pretty early when I am there. Unfortunately Helge is right in that there is a problem with recurrences, daylight shifting and timezones. Currently each client will use their understanding of daylight shifting and this does not work for some cases. On the other hand, we do have a problem with recurrences anyway. This is definately something we need to get at. First I want 2.0 of the spec getting out. (Comments from client implementors regarding other ideas were sparse on the list lately, are you sure there aren't any other issues a Kontact comment is open? ;) ) Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. 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: not available Type: application/pgp-signature Size: 206 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-format/attachments/20090205/87f617c8/attachment.bin From wrobel at pardus.de Thu Feb 5 15:57:39 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 05 Feb 2009 15:57:39 +0100 Subject: timezones, question of In-Reply-To: <200902051036.24665.bernhard@intevation.de> References: <200902042104.59159.till@kdab.net> <200902051036.24665.bernhard@intevation.de> Message-ID: <20090205155739.24255z5z52u13a0w@webmail.pardus.de> Quoting Bernhard Reiter : > Till, > > On Mittwoch, 4. Februar 2009, Till Adam wrote: >> 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. > > I believe Kontact should display the time in your local timezone, > which works, because it knows which timezone you have set it to when > looking at the event. > >> 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. > > As long as you have the time, I do not think it matters in which timezone you > have created the appointment. Which hints at another problem of the Kolab format: For full day events we drop the time information and here we really loose critical information if the event does not take place in our own timezone. Cheers, Gunnar > Hm I guess I would need to understand the use > case better. Probably you are using the timezone display for calculating the > time for others, like uh, this will be local time 7am so it is pretty early > when I am there. > > Unfortunately Helge is right in that there is a problem with recurrences, > daylight shifting and timezones. Currently each client will use their > understanding of daylight shifting and this does not work for some cases. > On the other hand, we do have a problem with recurrences anyway. > This is definately something we need to get at. > First I want 2.0 of the spec getting out. > (Comments from client implementors regarding other ideas were sparse on the > list lately, are you sure there aren't any other issues a Kontact comment is > open? ;) ) > > Bernhard > > -- > Managing Director - Owner: www.intevation.net (Free Software Company) > Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. > Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 > Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-format/attachments/20090205/1f36c048/attachment.bin From joon at radleys.co.za Thu Feb 5 19:22:56 2009 From: joon at radleys.co.za (Joon Radley) Date: Thu, 5 Feb 2009 20:22:56 +0200 Subject: timezones, question of In-Reply-To: <200902042104.59159.till@kdab.net> References: <200902042104.59159.till@kdab.net> Message-ID: <000b01c987be$c71b9760$5552c620$@co.za> Hi Till, > 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 Simplest solution would be to keep the time in UTC and create and optional field "associated-timezone". In this you put the time zone information you want to associate with this calendar event. Clients can the decide how to display the information, but as the information itself is can be safely ignored there will be no impact on current clients. If would suggest that we have a timezone offset to UTC preceding any TZID we end up choosing so that clients do not rely on specific databases. Best Regards Joon Radley Radley Network Technologies CC Cell: +27 (0)83 368 8557 Fax: +27 (0)12 998 4346 E-mail: joon at radleys.co.za Web: www.toltec.co.za From joon at radleys.co.za Thu Feb 5 19:38:34 2009 From: joon at radleys.co.za (Joon Radley) Date: Thu, 5 Feb 2009 20:38:34 +0200 Subject: timezones, question of In-Reply-To: <20090205155739.24255z5z52u13a0w@webmail.pardus.de> References: <200902042104.59159.till@kdab.net> <200902051036.24665.bernhard@intevation.de> <20090205155739.24255z5z52u13a0w@webmail.pardus.de> Message-ID: <001201c987c0$f6a30840$e3e918c0$@co.za> Hi Gunnar, > > As long as you have the time, I do not think it matters in which > > timezone you have created the appointment. > > Which hints at another problem of the Kolab format: For full day events > we drop the time information and here we really loose critical > information if the event does not take place in our own timezone. This is a tricky one. How would you associate Christmas day or new year with timezone information? Would they change to another day from another timezone perspective? Birthdays and anniversaries is another issue if the person is in a big timezone difference. You can send them a message and they will only receive it the next day if they have gone home already. This would require events with timezone perspective, which will drive everyone nuts. All day events are exactly that a day. If you want to schedule and event that will last the "whole" day, you create a normal event starting at 08:00 with a duration of 8 hours. Best Regards Joon Radley Radley Network Technologies CC Cell: +27 (0)83 368 8557 Fax: +27 (0)12 998 4346 E-mail: joon at radleys.co.za Web: www.toltec.co.za From helge.hess at opengroupware.org Thu Feb 5 22:53:16 2009 From: helge.hess at opengroupware.org (Helge Hess) Date: Thu, 5 Feb 2009 22:53:16 +0100 Subject: timezones, question of In-Reply-To: <20090205155739.24255z5z52u13a0w@webmail.pardus.de> References: <200902042104.59159.till@kdab.net> <200902051036.24665.bernhard@intevation.de> <20090205155739.24255z5z52u13a0w@webmail.pardus.de> Message-ID: <532DBEC4-BD12-443C-8908-3585667FF5B9@opengroupware.org> On 05.02.2009, at 15:57, Gunnar Wrobel wrote: > Which hints at another problem of the Kolab format: For full day > events we drop the time information and here we really loose > critical information if the event does not take place in our own > timezone. This is also a difficult issue, mostly because its difficult for the user to understand. From a technical perspective there are two kinds of full day events (actually it applies to any time value): a) floating b) fixed For example a birthday is a typical floating full day event. It doesn't matter which timezone you are in - it goes from 0:00-23:59 in any timezone. This does not only apply to allday. For example you could have an event like 'wake me at 8am'. Timezone or DST doesn't matter for that, you always need to get up at 8, whether you are at a US customer site or in Europe. I've never understood why you dropped iCalendar as the entity format. Its not complex due to design by committee, but because the domain _is_ that complex. If you start enhancing the XML to support what is actually necessary, you quickly end up with iCalendar ... Solution: just revert back to the iCal based Kolab format! ;-) After all Kontact has one of the best and most complete iCalendar implementations! Greets, Helge -- Helge Hess http://helgehess.eu/ From helge.hess at opengroupware.org Fri Feb 6 02:33:41 2009 From: helge.hess at opengroupware.org (Helge Hess) Date: Fri, 6 Feb 2009 02:33:41 +0100 Subject: timezones, question of In-Reply-To: <200902051036.24665.bernhard@intevation.de> References: <200902042104.59159.till@kdab.net> <200902051036.24665.bernhard@intevation.de> Message-ID: <8B182923-EF54-4B35-BC89-908AAD3CC9D3@opengroupware.org> On 05.02.2009, at 10:36, Bernhard Reiter wrote: > Unfortunately Helge is right in that there is a problem with > recurrences, > daylight shifting and timezones. Currently each client will use their > understanding of daylight shifting and this does not work for some > cases. I'm not sure I can follow you. It does work in _no_ case for recurrences which span timezones with different DST rules?! Eg the super simple case, USA recurrences displayed in Europe, does not work properly at all. BTW: AFAIK the most difficult case is Brazil, where the DST shifts are redeclared _every_ year. Hence you can't even convert a date like 2011-03-06 16:00 BRT to UTC. It will only be decided in 2010 whether that will be 13:00 or 14:00 UTC. Even iCalendar can't deal with it ... (since TZID must point to a VTIMEZONE, which in turn must contain the tz rule). Timezones are lovely, aren't they? ;-) Helge -- Helge Hess http://helgehess.eu/ From martin.konold at erfrakon.de Fri Feb 6 17:27:28 2009 From: martin.konold at erfrakon.de (Martin Konold) Date: Fri, 6 Feb 2009 17:27:28 +0100 Subject: CVS Note: additions to mail folder subtypes Message-ID: <200902061727.28911.martin.konold@erfrakon.de> Hi, I just added the two new mail folder subtypes "outbox" and "wastebasket". Most offline capable Kolab clients will never use these but for others clients they can be useful in order to remain language neutral. diff -u -u -r1.10 folders.sgml --- folders.sgml 14 Nov 2007 11:59:03 -0000 1.10 +++ folders.sgml 6 Feb 2009 16:24:03 -0000 @@ -33,9 +33,11 @@ The <type> can be: mail, event, journal, task, note, or contact. -The <subtype> for a mail folder can be inbox, drafts, sentitems, -or junkemail (this one holds spam mails). For the other <type>s, it +The <subtype> for a mail folder can be inbox, drafts, sentitems, outbox, wastebasket +or junkemail (this one holds spam mails). For the other <type>s the <subtype> can only be default, or not set. + +Note: Most offline capable Kolab clients will not synchronize outbox or wastebasket. There MUST NOT be two folders of a single type having the default subtype. E.g. it is forbidden to have two folders of the type calendar with the subtype default within one Kolab Yours, -- martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstra?e 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ From bernhard at intevation.de Mon Feb 9 11:51:22 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 9 Feb 2009 11:51:22 +0100 Subject: iCalendar vs XML (was: timezones, question of) In-Reply-To: <532DBEC4-BD12-443C-8908-3585667FF5B9@opengroupware.org> References: <200902042104.59159.till@kdab.net> <20090205155739.24255z5z52u13a0w@webmail.pardus.de> <532DBEC4-BD12-443C-8908-3585667FF5B9@opengroupware.org> Message-ID: <200902091151.25082.bernhard@intevation.de> Helge, On Donnerstag, 5. Februar 2009, Helge Hess wrote: > I've never understood why you dropped iCalendar as the entity format. this is an old question, read it up in the archives. I had several very good people tell me it would work as a storage format and when they got down trying to implement it, they came back (10 days) later saying it is not possible to get it right. > Its not complex due to design by committee, but because the domain ? > _is_ that complex. The format is too ambigious for a storage format. > If you start enhancing the XML to support what is actually necessary, ? > you quickly end up with iCalendar ... Solution: just revert back to ? > the iCal based Kolab format! ;-) After all Kontact has one of the best ? > and most complete iCalendar implementations! Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. 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: not available Type: application/pgp-signature Size: 206 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-format/attachments/20090209/d7d446dc/attachment.bin From bernhard at intevation.de Mon Feb 9 11:52:26 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 9 Feb 2009 11:52:26 +0100 Subject: CVS Note: additions to mail folder subtypes In-Reply-To: <200902061727.28911.martin.konold@erfrakon.de> References: <200902061727.28911.martin.konold@erfrakon.de> Message-ID: <200902091152.26733.bernhard@intevation.de> On Freitag, 6. Februar 2009, Martin Konold wrote: > I just added the two new mail folder subtypes "outbox" and "wastebasket". > Most offline capable Kolab clients will never use these but for others > clients they can be useful in order to remain language neutral. Thanks, should be considered for 2.0.1 or 2.1 of the specs then. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. 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: not available Type: application/pgp-signature Size: 206 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-format/attachments/20090209/14c3a308/attachment.bin