[Kolab-devel] [Kde-pim] Heads-up: Two changes to the Kolab format that are going to affect KDE PIM
Georg C. F. Greve
greve at kolabsys.com
Tue Nov 23 12:41:05 CET 2010
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>
More information about the format
mailing list