KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
wrobel at pardus.de
Mon Nov 29 18:04:27 CET 2010
Quoting Hendrik Helwich <h.helwich at tarent.de>:
> Am Montag, 29. November 2010 11:36:21 schrieb Georg C. F. Greve:
>> Hi Hendrik,
>> Thank you for your attempt of summarizing your perspective.
>> Allow me to quickly respond to some of the points:
>> On Monday 29 November 2010 11.00:41 Hendrik Helwich wrote:
>> > Our reasoning is as follows:
>> > We think the strict Zulu UTC format will be a better solution than
>> > allowing all the various RFC3339 possibilities, because it is much
>> > simpler, hence far less error-prone. It is far easier to implement than
>> > RFC3339, without the need to resort to an external library,
>> The same argument could be made against using X Windows, in favor of
>> creating your own visual output routines. StarOffice once followed that
> This comparison is not fitting very well, because there is no need to
> implement a parser for the strict Zulu format. You have system libraries for
> that in programming languages like C, Java, etc.
>> The counter-argument is that more, newer, and less tested code is always
>> likely to have more errors than using the well-tested system functions.
>> Also, maintenance of your own code will be on yourself only, while system
>> code relies on the upstream, and - if erroneus - would affect all programs,
>> so is likely to get fixed quickly.
> there is no need to implement this on your own.
Yep, we already have the required implementation.
>> > and has the advantage that not every Kolab client needs to be adapted.
>> All clients will necessarily be changed in their time handling for KEP2,
>> there is no way around that, as the old storage format had the shortcoming
>> you identified.
> But using the strict Zulu format, clients which do not implement the KEP2
> could still parse the new format correctly and display them correctly for
> events without recurrence.
Well, but they might fail with events that carry the additional
> This is another small pro for the strict Zulu format i would say
>> > Existing clients can just rely on the Kolab format specification as is.
>> Due to the issues laid out in the KEP, the version number will need to
>> change for this KEP, so older clients should - if implemented correctly -
>> no longer work on such objects.
Which section of the Kolab format description at
http://kolab.org/doc/kolabformat-2.0-html/ mentions this? I didn't
find it and it is also not implemented in Kolab_Format from Horde.
>> > The RFC3339 time format adds much more complexity to the Kolab format
>> > without adding any significant advantage.
>> In my view the ability to integrate more technologies into Kolab is a major
>> advantage, and most of those technologies rely upon RFC3339 for their
>> storage of datetime, and some of them require the precision it offers.
I currently have to agree with Hendrik and see no compelling reason
for RFC3339. I don't see what it would give us right now and I
consider it more important to get the core issue of recurrences over
DST done. RFC3339 does not seem to help there.
>> > Regarding the second issue we think that it is better to have a
>> > self-contained Kolab event type than introducing a dependency on an
>> > external time zone database.
>> As pointed out by David Jarvie, iCalendar provided proof this concept is
>> broken for a variety of reasons, including that there will always be
>> clients which trust their own sources more than what is stored in the file.
> The kolab format specification should define how clients must calculate the
> times which are shown to the user. If the timezone information is included in
> the kolab format (like it is done in iClanedar) it can be assured that all
> people see the correct times.
> If some clients do the calculation in an other way than specified, it surely
> can happen that the displayed time is wrong. But this can happen in any
> When using an external time zone database it cannot be assured that the
> displayed times are correct.
>> > Time zone information is subject to change,
>> That is precisely why storing it statically in the file is not a good idea.
>> Yes, there is the possibility that very old systems (5yrs+) will come out
>> of sync if they do not update their time zone database.
>> But then the entire system will consistently be out of sync.
>> And that is a temporary situation.
> But this will be common scenario and the times are calculated differently for
> different people.
> You will get bug reports all the time and it will be very hard to debug this
> kind of problems and to solve them because this is fixed by the design of the
> kolöab format.
>> The corresponding RFC to fix this issue is being worked on right now, and
>> once it has become commonly used, this danger will disappear for all
>> devices connected to a network, which seems a valid assumption for Kolab
>> Now re-implementing a concept that we already know to have failed in
>> practice seems a bit like re-inventing a static storage of time
>> synchronization between clients at a time when NTP was already being worked
I still have to reread the discussion of the tz database. Will comment
on that later.
>> > Since most people on this list seem to have a similar opinion [...]
>> While I respect your desire to have everyone else follow the path you chose
>> with your implementation and see how that can color perception, I'd suggest
>> to be slightly more careful with implying majorities.
> You misunderstand my motivation. I just have to work with the kolab
> format for
> a project. I see the problems of the KEP2 and would like to discuss them
> until we solve this problems. There is no need to follow the path i chose :-)
> There is also no need to be offended by a technical discussion on the KEP2.
Actually I'm already happy that we have this KEP process now and that
it fosters such discussions. We didn't have a lot of movement in the
past years and it is great to see that the format is finally seeing
Of course some of these discussions take a long time but as this is
the core of the Kolab concept I actually don't mind as long as we find
a common ground.
> Best regards
>> The input and opinions we've seen so far has been fairly diverse, and the
>> KEP reflects that diversity of viewpoints, as all clients would need to
>> address these changes.
>> Best regards,
> Kolab-format mailing list
> Kolab-format at kolab.org
____ 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 <<
More information about the format