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

[Florian v. Samson]

Till, 

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

All other statements you made in your mail below are only true for a single 
client: *Kontact*.  
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.

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

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

-"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.  
As I pointed out, becoming a single-client Groupware-solution is an quite 
dangerous route to take for Kolab.

Quite disappointed
	Florian