[Kde-pim] Re: KEP #2: Closing call

[Bernhard Reiter]

Am Montag, 14. Februar 2011 15:23:19 schrieb Jeroen van Meeuwen (Kolab 
Systems):
> Therefor, you will now have *two weeks* to raise any further objections
> against the current revision of the design enhancement proposal:
>
>   http://wiki.kolab.org/index.php?title=KEP:2&oldid=10864

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
   http://lists.kde.org/?l=kde-pim&m=129863167919942&w=2
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 
matter.) 

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.

Best,
Bernhard
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. 

[1]  http://community.kde.org/KDE_PIM/Meetings/Osnabrueck_9

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20110227/f9407a62/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/