KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
h.helwich at tarent.de
Mon Nov 29 14:20:44 CET 2010
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.
> > 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.
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.
> > 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.
> > 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
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
> 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
> > 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.
> 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,
More information about the format