KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
Georg C. F. Greve
greve at kolabsys.com
Mon Nov 29 11:36:21 CET 2010
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.
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.
> 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
> 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.
> 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.
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.
> 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.
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
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format