KEP 2: Modification of datetime type, introduction of 'tz' sub-tag

Gunnar Wrobel wrobel at
Mon Nov 29 18:04:27 CET 2010

Quoting Hendrik Helwich <h.helwich at>:

> 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
>> path.
> 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  
timezone information.

> 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 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.
> With this argument we could also add JavaScript to the Kolab Format ;-)

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
> scenario.
> 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
>> clients.
>> 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
>> on.

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  
movement again.

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
> Hendrik
>> 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,
>> Georg
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at

____ _________________ _

E-mail : p at                                 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 mailing list