KEP-0002.txt

Georg Greve greve at kolabsys.com
Tue May 31 11:24:34 CEST 2011


 KEP-0002.txt |   20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

New commits:
commit d65b0bed2223acd8ac53db624d14d978f123e1fb
Author: Georg Greve <greve at kolabsys.com>
Date:   Tue May 31 11:25:43 2011 +0200

    Last round of changes based on feedback from Florian von Samson

diff --git a/KEP-0002.txt b/KEP-0002.txt
index 46d7756..8391071 100644
--- a/KEP-0002.txt
+++ b/KEP-0002.txt
@@ -18,7 +18,7 @@ This is a Kolab Enhancement Proposal (KEP)<ref name"kep">[[KEP:1]]</ref> to upda
 
 This KEP addresses issues of usability as well as function. The usability related issue is that users sometimes specifically set time zones for datetime fields and expect this explicit selection to be preserved across sessions and clients. Without storage of this information clients cannot meet that user expectation.
 
-The functional issue is the more important of the two: For non-recurring events there can be errors in the display of an event's time if DST rules have changed since the event was made. For recurring events in parts of the world with DST regimes it was impossible to define a recurrence that takes place at the same local time all year and is correctly displayed by clients in time zones with different DST rules, in particular different times of switching. Both issues are accentuated by the fact that DST rules are subject to political decisions taken in the future, and consequently unknown today.
+The functional issue is the more important of the two: For non-recurring events there can be errors in the display of an event's time if DST rules have changed since the event was made. For recurring events in parts of the world with DST regimes it was impossible to define a recurrence that takes place at the same local time all year and is correctly displayed by clients in time zones with different DST rules, in particular different times of switching. Both DST-related issues are accentuated by the fact that DST rules are subject to political decisions taken in the future, and consequently unknown today.
 
 In order to achieve a recurring event that retains its local time across DST transitions, a client must know which time zone to use. The implicit assumption of older clients to always use local time zone is problematic, as explained in subsection "Description of current client behaviour" below. So enabling time zone information for datetime fields is essential.
 
@@ -54,7 +54,7 @@ Based on {{rfc|3339}} <ref name="rfc3339">{{rfc|3339|title=Date and Time on the
 
  date-time       = full-date "T" full-time
 
-The "Z" to specify a time in UTC '''MUST''' only be used for times in UTC and '''MUST NOT''' be added to values in local time.
+The "Z" to specify a time in UTC '''MUST''' be used for times in UTC and '''MUST NOT''' be added to values in any time zone other than UTC.
 
 Per ABNF, ISO8601 and RFC3339, the "T" and "Z" characters in this syntax are explicitly defined as the upper-case letters, usage of the lower-case letters is explicitly forbidden.
 
@@ -112,7 +112,7 @@ Valid date-time fields according to the above definition are
 
 * When creating a new object with time zone sensitive fields, clients '''SHOULD''' default to the local time zone of the user, but '''SHOULD''' allow the user to select the time zone for storage and consequently recurrence calculation;
 * When modifying existing objects, clients '''MUST''' use the value of the 'tz' attribute of the respective fields to set the default/preselected value for the editing of the fields, where applicable. For instance the 'start-date' and 'end-date' time zone defaults if presented to the user by the client '''MUST''' match those stored in the 'tz' attribute. The time zone stored in the 'tz' attribute '''SHOULD''' only be changed based upon user interaction;
-* When calculating recurrences, a client '''MUST''' calculate in a way that keeps the event at the same local time in the time zone stored in the 'tz' attribute. Clients '''MUST''' then use the result as the time from which to calculate the time of the event at the client's time zone. For more detail see [[#Notes_for_client_implementors | Notes for client implementors]] below);
+* When calculating recurrences, a client '''MUST''' calculate in a way that keeps the event at the same local time in the time zone stored in the 'tz' attribute. Clients '''MUST''' then use the result as the time from which to calculate the time of the event at the client's time zone. For more details see [[#Notes_for_client_implementors | Notes for client implementors]] below;
 * When receiving iTip invitations, a client '''MUST''' treat the time zone id in the VTIMEZONE object as authoritative and, if it is not a valid Olson database time zone identifier, translate it using the tzid mapping table provided by the Kolab community. If the time zone id in the VTIMEZONE element does not exist in the tzid mapping table, clients '''MAY''' attempt to map the time zone based on its rules to a currently used time zone -- '''AND/OR''' -- allow the user to select an appropriate time zone for storing an event;
 * For recurrence calculation: When tz is specified as 'UTC', a client '''MUST''' calculate recurrences strictly according to UTC;
 * For recurrence calculation: Where tz is missing although the Kolab Format required it, a client '''SHOULD''' calculate recurrences strictly according to UTC;
@@ -236,7 +236,7 @@ Existing clients currently make the implicit assumption that the time was specif
 
 A weekly meeting is set for 11:00 every Wednesday in Zurich, Switzerland, starting on 23 June 2010. This gets translated stored in UTC as 2010-02-17T09:00:00Z. On Wednesday 17 February 2010 Switzerland is using standard time, the local timezone is therefore UTC+1. If strictly interpreting the stored information, the meeting should now start at 10:00. 
 
-Versions of KDE Kontact <=4.6.3 however display the meeting as scheduled for 11:00. The same is true for the Kolab web client based on Horde for versions of Kolab Server <= 2.2.4. This however is equivalent to 10:00 UTC. When adding another user in Sao Paulo, Brazil to the equation, the event is shown as taking place at 06:00 local time, or 08:00 UTC, due to the Brazilian summer time with an offset of UTC-3 that went into the assumption for the calculation of the recurrence. The result is that two users, while being presented with a data set that looks consistent, will miss each other.
+Versions of KDE Kontact <=4.6.3 however display the meeting as scheduled for 11:00. The same is true for the Kolab web client based on Horde for versions of Kolab Server <= 2.2.4. This however is equivalent to 10:00 UTC. When adding another user in Sao Paulo, Brazil to the equation, the event is shown as taking place at 06:00 local time, or 08:00 UTC, due to the Brazilian DST with an offset of UTC-3 that went into the assumption for the calculation of the recurrence. The result is that two users, while being presented with a data set that looks consistent, will miss each other.
 
 Which other clients exhibit the same behavior is unclear, but it seems there is no reasonable assumption that current behavior correctly models any rational use case.
 
@@ -253,14 +253,12 @@ To address all the known issues, this information would have to include the enti
 Ultimately this approach would lead towards storing time zone data in the objects themselves in order to achieve consistency and security to preserve the intent of the user. This brings several pitfalls because time zone data is subject to change, in particular:
 
 * Clients may not be allowed to update, e.g. for shared calendars with only read permission;
-* Clients that "know" data to be outdated but cannot update the object may in fact prefer to present the user with a correct event, rather than displaying a wrong event consistently, which is behavior that has been observed in iCalendar clients, which have double storage of TZID & in-format data;
-* There are no good indicators when in-format data should be updated. Without these a client with the old timezone data would feel the urge to update the object again, in effect rolling the update back;
-* Periodic checks for updates would have to happen often if clients are required to do the updates. This will complicate objects and requires those clients to have access to other, authoritative sources;
+* Clients that "know" data to be outdated but cannot update the object may in fact prefer to present the user a correct event, rather than displaying a wrong event consistently. This behavior has been observed in iCalendar clients, which have storage of both TZ-ID & in-format TZ-data;
+* No good indicators exist when in-format TZ-data should be updated. Without these a client with the old timezone data would feel the urge to update the object again, in effect rolling the update back;
 * Substantial size would be added to the event, often VTIMEZONE definitions can be larger than the data for the event itself. If more than one timezone is used, each timezone has to be within the object. As many appointments will be in the same timezone, the data within a folder or a Kolab account and server will be highly redundant;
-* Once a client notices the need for an update, many objects would be effected which would lead to the need of a lot of data transfer and backup space to update the redundant data. Backup space is expensive;
-* A client could only notify the user if it encounters an object in need of a timezone update when the folder is read-only. Again this could be many objects.
+* Once a client notices the need for an update, many objects would be affected which would lead to the need of a lot of data transfer and backup space to update the redundant data.
 
-But the most substantial argument is the problem of finding a good algorithm that will determine when an update of the time zone data stored in the objects should be done. As there is currently no serial number of authoritative data attached to this information, such a mechanism would have to be invented and would further complicate implementation of this KEP.
+The most substantial argument is the problem of finding a good algorithm that will determine when an update of the time zone data stored in the objects should be done. As there is currently no serial number of authoritative data attached to this information, such a mechanism would have to be invented and would further complicate implementation of this KEP.
 
 Therefore the principle of storing local time (understanding UTC as one possible time zone) along the lines of '''store what you mean''' has come out as the preferred option for most participants in the discussions, and all participants could accept this approach. 
 
@@ -283,7 +281,7 @@ The Olson database is specifically mentioned recommended in the VTIMEZONE sectio
 * several other Unix systems, including Tru64, and UNICOS/mp (also IRIX, still maintained but no longer shipped).
 * Python via pytz module
 
-Choosing the Olson time zone identifiers will simplify matters for all clients on the above platforms or using the above languages.
+Choosing the Olson time zone identifiers will simplify matters for all clients on the above platforms or using the above programming languages.
 
 The issue of most concern is that Microsoft Windows has its own time zone identification system. A bridge is however provided by the Unicode Common Locale Data Repository (CLDR) as well as the International Components for Unicode (ICU). The CLDR also provides mapping for Microsoft Windows time zone IDs to the standard Olson names. So using references to the Olson timezone database is likely the best out of an imperfect set of choices.
 





More information about the commits mailing list