[Kolab-devel] [Kde-pim] Heads-up: Two changes to the Kolab format that are going to affect KDE PIM

[Georg C. F. Greve]

Hi David,

On Wednesday 17 November 2010 17.59:08 David Jarvie wrote:
> I'm not sure that the Smart Upgrade Option is a good idea. If a client
> performs the smart upgrade, the recurrence will appear to have been
> created by a client using the new format, but if the smart upgrade
> assumptions are wrong (i.e. the time zone is not the local time zone), the
> recurrence times will be wrong. 

> If it was left in the old format, so that clients can recognise that it
> doesn't have a specified time zone, it would then be open to the client (or
> another client) subsequently accessing the same calendar data to present the
> recurrence to the user as being uncertain.

Let me try to explain the thinking behind the option:

The smart upgrade option could obviously only ever be done by a client that 
understands the new format. So indeed the recurrence will then have been 
created by a client that understands the new format.

Because the same client that does the smart upgrade would likely be the same 
one that previously incorrectly displayed the recurrence, it would then update 
the recurrence to match previously exhibited behaviour, which is likely to be 
closest to what the user has seen before and has come to expect.

To do that you are completely correct it has to make an assumption about the 
timezone, which might be different from user expectation.

But new clients MUST treat files without explicit time zone strictly according 
to UTC, as that is how new clients would specify such recurrences, so the 
recurrence will be guaranteed to be different from user expectation in order to 
at least be consistent.

So the smart upgrade option would require user intervention only for where the 
guess was wrong. This will be the case where (a) the user has meanwhile 
switched time zones, or (b) there is involvement of users in two different time 
zones that were previously synchronized, but now no longer are.

My gut feeling also because this has not been discovered earlier is that 
(a)+(b) is below 10% of the cases, which would mean that while user 
intervention without smart upgrade will be necessary in 100% of the affected 
cases, it'll be required in less than 10% of the cases with smart upgrade. 

That seemed a "good enough" reason to have it as an option.

At the same time, because this involves some application side logic, I think 
it would be too much to require it from all clients.

Hence the phrasing it as an option.


> I think that only the user should be able to definitively specify the time
> zone when it's not already in the calendar. The client shouldn't do this
> without asking the user, since no information is lost by not asking.

Yes. I think that would also be good client behaviour. Maybe it should be 
added explicitly as another option. Personally, I'd suggest to then leave it 
up to the client implementors which path to choose, if any, because the 
alternative of not touching events and wait for users to notice the deviation 
from desired behaviour, and then fix it manually, is also possible.


Speaking of clients: There has been the question which functions are used in 
which clients for parsing & writing datetime stamps. 

Do you know whether KDE PIM uses a function capable of parsing RFC3339 
datetime stamps for its Kolab format parsing? It's writing RFC3339 for some 
fields would suggest so, but I wanted to be sure.

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/20101123/bae8217b/attachment.sig>