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

[Georg C. F. Greve]

Bernhard,

Let me try to point you to some of the results, as most of these have been 
discussed at great length already and laid to rest long before:

On Sunday 27 February 2011 18.12:37 Bernhard Reiter wrote:
> 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.

This is the simplest way of storing local time in a way that is both compliant 
with existing standards and backwards compatible with the old storage format.


> My suggestion is [...]

This would appear to be a new, standards-incompliant datetime format that only 
Kolab uses, with major potential for confusion and misinterpretation, because 
it would look like RFC3339 / UTC.

It has been discussed before, but several people, myself included, felt this 
was asking for trouble and not a very robust choice.


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

It will have to be mandatory for at least the user-determined fields, because 
that is the only way to ensure storage of user preference. So we'll have to 
make a list of which fields MUST be in the authoritative time zone, and which 
fields MAY be in the authoritative time zone.

This is a complication that I'd rather have avoided, also because it seemed 
unnecessary. Storage of authoritative time zone in all items increases human 
readability, as users don't have to try to calculate local times from UTC.

So there seems to be no clear case for preference on UTC storage that actually 
warrants such complication.

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

The KEP says that where the time zone can be edited it has to default to what 
the user selected, not that time zone selection has to be added to every 
single occurence of a datetime field.

Consistent client behaviour along the expectations of the user can only be 
achieved if all clients behave consistently, and thus a "must" form is chosen.


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

The mapping of local time to UTC and the other way around is a function of 
several parameters: location, the respective date, and (past and future) 
political decisions about daylight savings time.

If all three are perfectly well known, the relationship can be de-ambiguified.

Otherwise you have no way of knowing whether 10:00 UTC is 11:00 or 12:00 in 
Osnabrück, or whether 11:00 in Osnabrück is 09:00 UTC or 10:00 UTC.

When one thing can mean two or more other things, my understanding of the 
English lanugage is that that is called ambiguous.

But maybe a native speaker can help here.

In any case, this seems more of an editorial than substantial remark, and I 
wonder whether that is really worth holding up the resolution of this issue 
now.


> Please give the precise Kontact version for the example in "Recurring
> Events". The example cannot be fully reproduced and understood without it.

I've tried it with multiple versions, which all showed the same behaviour, and 
also got reports from customers of the enterprise 3.5 version that it shows 
this behaviour. Because the old format as an actual bug and cannot map this 
case properly, that is to be expected.


> 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 

I don't think that "we don't know what Microsoft is going to do in the future" 
should be a blocker for making a technological decision for Kolab. Naturally 
the lack of standardization on that platform always makes interoperability 
more difficult, but that's why we'll be helping with a mapping database, on 
which your help would be greatly appreciated.

Overall it's a call of least issue for smallest group, as otherwise all other 
systems would have to do mapping databases from Windows time zones with 
mapping of undocumented platform specific quirks.


> (I have not had the time to look up the latest posts on the matter.)

There have been no latest posts on the matter. Despite several reminders that 
it was entering closing stage, there has been no more feedback on the KEP for 
six weeks or more now. 


So the question now is: Does the above answer your questions, or do you want 
to maintain sustained opposition on any of the points above?

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110228/4e5e77f9/attachment.sig>