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

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

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


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

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101129/010128ed/attachment.sig>