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

[Hendrik Helwich]

Hi Gunnar,

Am Montag, 29. November 2010 18:04:27 schrieb Gunnar Wrobel:
> 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 right. Events with recurrences could be shown wrong but this would be 
like it is done right now in kolab clients.
At least events without recurrences could be visible (with the correct time) 
in old kolab clients.

Best regards,

Hendrik