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

Gunnar Wrobel 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
>> 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.

+1

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

Cheers,

Gunnar

>
> 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 kolab.org
> https://kolab.org/mailman/listinfo/kolab-format
>



-- 
____ 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 mailing list