KEP #2: Closing call
bernhard at intevation.de
Sun Feb 27 18:12:37 CET 2011
Am Montag, 14. Februar 2011 15:23:19 schrieb Jeroen van Meeuwen (Kolab
> Therefor, you will now have *two weeks* to raise any further objections
> against the current revision of the design enhancement proposal:
with is about the Kolab Storage XML format:
(KEP 2: Modification of datetime: store local time, add 'tz' attribute)
> This closing call lasts until *17:00 UTC on Monday, February 28th, 2011*,
I reread the current draft (id=10864) today,
because I had input in the last days from
a) an invitation compatibility test with Outlook I did, see
b) a discussion about the invitation compatibility and storage
with Andre Heinecke and Sergio Martins
during the KDEPIM Dev Osnabrück Meeting today.
Lots of work has gone into the KEP2 and this is highly appreciated!
The effort made to document the difficult discussion is very laudable.
The good news:
In our discussion we liked the change towards storage
as localtime with "tz" id as proposed in the current KEP2.
Additional information: On single instance events we will change Kontact to
send out invitations only as UTC by default. This is a tradeoff decision
based on the assumption that a significant number of clients will have
trouble interpreting VTIMEZONE information correctly. This can be reconsidere
in the future, if we know more about the distributon of clients.
For recurrent events, we will use TZID with VTIMEZONE information.
It is a different story for storage, we believe in localtime with "tz" there.
The bad news:
Personally I object to the requirement to parse datetime according to RFC 3339
and the wished capability to parse datetime fields by ISO 8601.
Rational: I did not read a compelling reason to do so.
The note on "strict writing - loose parsing" mentions a primary Kolab client
writing incompliant datetime fields as only reason. For Kontact I am not
aware of any relevant version writing bad datetimes. Relevant means that it
was recommended for use as a Kolab Client and not a development version. The
normal reaction here in my view would be to fix the broken client or migrate
the broken data once. If that client is so important to not solve this case
with a migration script, the client product and version should be explicitely
given and importance explained. My suggestion is to only require
YYYY-MM-DDTHH:MM:SS[.SS][Z] so with 'Z' being optional and fractions of a
second being optional.
I object to the requirement that all clients must store _all_ datetime fields
in the authoritative time zone. For many datetime fieldd, like the last
modification or creation, UTC would be enough and even slightly prefered in
my view. Suggestion: Change this to MAY or give a better reason.
I object to makeing it a requirement in the "notes for client implementors"
for clients to default to the stored time zone in all cases. For single
instance events this looks only like a recommendation to me. Otherwise
it might force the user interface to display the time zone in simple cases as
well and thus become a nuisance for the user interface.
Reading the description of the issue I believe the described "ambiguity"
between UTC and a local time is misslabled. The mapping between a single UTC
datetime and a localtime is bi-directional as far as I can tell. So it is well
defined and not ambiguous. Ambibuous is what the user really wants and what
he might get in case of some changes.
I agree that most users will want the event to stay at 11 hours local time
even when the DST and the timezone definition changes. I would describe this
as the problem that users usally want and thus mean "local time".
Subsequently the adjective "wrong" is used when a violation of this users
expectation is meant. As this user expectation is an assumption, rephrasing
this would help the understanding of the section.
(This is only a suggestion to improve the argument here. I am not objecting to
the underlying thought as far as I understand them.)
Please give the precise Kontact version for the example in "Recurring Events".
The example cannot be fully reproduced and understood without it.
And the behaviour is likely to change.
I am a bit concerned that some outlook clients might have a hard time to
implement the Olson names. They certainly can ship their own Olson database
and they also write the Kolab Storage XML object, so they control it there.
But they might not control how Outlook will expand one of the recurring
objects. On the other hand, Outlook must be able to deal with arbitrary
VTIMEZONE in invitations, if it can do this, they should be able to
deal with arbitrary olson entries as well. Naturally outlook developers
know that best and (I have not had the time to look up the latest posts on the
Despite the objections, I believe that we are closing of getting KEP2 done.
Our discussion today gave us confidence that the core proposal is fine:
Store stuff as local time and tz id.
I am sorry that the feedback is coming so late, this was triggered
by of the new information of Thursday and the good discussion we had today.
ps: This contains a summary of a pim discussion, this is why I've send a copy
to kde-pim at . Regular followups to kolab-format@ only please.
Managing Director - Owner: www.intevation.net (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the format