KEP #2: datetime RFC3339 and ISO 8601 and requirement of tz

[Till Adam]

On Wednesday 02 March 2011 15:09:42 Florian v. Samson wrote:

> "[KEP#2 is ]backwards compatible with the old storage format." is not at all
> true.  Changing any definition of an existing tag always breaks backward
> compatibility.

True. I don't remember saying otherwise, but your quote seems to indicate I 
did.

> All other statements you made in your mail below are only true for a single
> client: *Kontact*.

I don't think it's quite that black and white, but my perspective is slanted 
towards Kontact, obviously, since that's what I primarily work on.

> They do not hold true for almost every other Kolab-client, e.g.:
> 
> - "RFC 3339, because we can rely on platform implementations."
> No, most clients cannot: they either have to implement a RFC3339 parser
> themselves or install a RFC3339 parsing library.

Which I assumed to be present, indeed. If that's not the case, then a simpler 
format is indeed a good idea.
 
> - "As Georg points out, no one wants to implement _any_ date format
> themselves, all platforms provide workable implementations, which
> interoperate."
> Sorry that is not true: Not all programming environments of the
> Kolab-clients provide workable implementations.  But definitely true is
> that "no one wants to implement _any_ date format themselves", but some
> have to: with the existing date-time format this is no big deal, with
> RFC3339 this becomes a major effort.

Again, I was under the assumption that the RFC is sufficiently widely 
implemented in the relevant environments. You're thinking of a particular one 
that does not, I assume, may I ask which? I was looking at Qt, obviously, but 
also PHP and the Windows API.

> -"It's not relevant in the contact editor."
> Kolab-clients do differ a lot: while this may be true for Kontact, it is
> definitely untrue for most other clients.

Fair enough.

> -"Bernhard, we, the Kontact implementors, were consulted in this process and
> gave our input, objections and judgement months ago. The KEP incorporates
> our feelings on the matter."
> At least now I do understand after all these months of confusion on this
> list why the input from all other Kolab-client initiatives and vendors have
> been ignored in the current KEP#2: in order to cater Kontact and its
> programming environment perfectly.

I don't think that was either the intention nor in fact what happened. I was 
merely pointing out that Bernhard, who was identifying himself to be 
representing the Kontact developers, was not, in fact, the only representative 
of that group, and that we had been previously consulted. As were the other 
implementation teams, I should hope. At least the strong impression I got from 
talking to the authors of the KEP was that they were talking to everyone, not 
just us. 

> As I pointed out, becoming a single-client Groupware-solution is an quite
> dangerous route to take for Kolab.

Again, I don't believe that is anyone's intention, nor does it make sense. If 
you feel the process of this KEP pointed that way, then that is disappointing 
indeed, for everyone involved. I do hope the Kontact folks (in particular my 
team at KDAB) did not contribute to that, and if we did, I apologize on their 
behalf. 

Till

-- 
Till Adam | till.adam at kdab.com | Managing Director Germany
KDAB (Deutschland) GmbH & Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions