KEP #2: datetime RFC3339 and ISO 8601 and requirement of tz
Florian v. Samson
florian.samson at bsi.bund.de
Wed Mar 2 15:09:42 CET 2011
"[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
All other statements you made in your mail below are only true for a single
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
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.
More information about the format