summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGeorg Greve <greve@katana.(none)>2010-11-19 10:19:27 (GMT)
committerGeorg Greve <greve@katana.(none)>2010-11-19 10:19:27 (GMT)
commit6352c5dc3b292ed53530984d9ed92b190373b063 (patch)
tree6453432b264da6b56cb52c2cba032df91f1c53e5
parent2b76e712cba5909734854afa2ff89f47b7637b29 (diff)
downloadkeps-6352c5dc3b292ed53530984d9ed92b190373b063.tar.gz
Added some more background based on the discussion to allow others to better understand what has been considered thus far.
-rw-r--r--KEP-0002.txt60
1 files changed, 42 insertions, 18 deletions
diff --git a/KEP-0002.txt b/KEP-0002.txt
index d6483bf..f7b031a 100644
--- a/KEP-0002.txt
+++ b/KEP-0002.txt
@@ -13,9 +13,9 @@
__TOC__
== Abstract ==
-Kolab used to store all times in UTC and did not allow for time zone information. For recurring events in parts of the world with Daylight Saving Time (DST) regimes this means the time of the event is changing, as DST is defined in a '''dynamic''' offset towards UTC.
+Kolab used to store all times in UTC and did not allow for time zone information. For recurring events in parts of the world with Daylight Saving Time (DST) regimes this means the time of the event is changing, as DST is defined in a '''dynamic''' offset towards UTC with the dynamics being 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 "Description of current client behaviour" below. So enabling time zone information for datetime fields is essential.
+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.
Some reference for background was provided on the Kolab format list <ref name="kolab-format-list-background">Georg Greve, http://kolab.org/pipermail/kolab-format/2010-October/001004.html</ref> and there have been various proposals for resolution of the issue, including adding time zone information in a separate XML tag, along with DST details <ref name="dst-details">Henrik Helwich, http://kolab.org/pipermail/kolab-format/2010-October/000999.html</ref>. This document is based upon those discussions and draws inspiration from the various proposals, resulting in the described update which follows the approach of least invasive change with least burden on client implementors.
@@ -41,17 +41,17 @@ Examples of valid 'start-date' fields using datetime structures according to the
* <start-date>1996-12-19T16:39:57-08:00<tz>America/Sao_Paulo</tz></start-date>
-Note: The first two examples are identical to the datetime type used in Kolab XML storage prior to this modification.
+{{note|While only the first conforms with the specification document, the first two examples are identical to the datetime type used in Kolab XML storage by reference clients prior to this modification.}}
When time zone information is provided, a client '''MUST''' consider the event local to this time zone. Recurrence '''MUST''' then be calculated to keep the event at the same local time within that time zone, adjusting the time for the event accordingly for the client's local time zone.
When no time zone information is provided, a client '''MUST''' calculate recurrences strictly according to UTC.
-When modifying objects, clients '''MUST''' preserve the original time zone used for storage.
+When modifying objects, clients '''MUST''' preserve the original time zone used for storage unless changed by user interaction.
When adding new objects, 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.
-== Upgrade Path ==
+=== Upgrade Path ===
All clients already must preserve all tags they do not understand. So the newly introduced 'tz' tag must be preserved by older clients that do not understand it.
@@ -59,23 +59,13 @@ There will be some change of client behaviour as older events now displayed in n
Unavoidably, older clients will continue to display recurrence times incorrectly. This is neither an improvement nor a deterioration of the current situation.
-== Smart Upgrade Option ==
+=== Smart Upgrade Option ===
Clients '''MAY''' choose to use the 'product-id' and absence of 'tz' tag to identify which event was created by an older client, and silently update it to have recurrence behave in the way the user expects. When doing so, it is recommended to assume the client's local time zone was the one for which the recurrence should be stable in local time, as that was what clients were assuming and showing to the user thus far.
As this provides a substantial amount of work for clients, this is '''NOT''' a requirement.
-== Background notes on backwards-compatibility ==
-
-This modification represents the least invasive change to redress the existing issues.
-
-While it is preferable to have correct recurrence calculation, it would be even better if this change could take place without notice by the user. This would only become possible if clients had the chance to differentiate between objects according to the format prior to this update, and those afterwards. This would require either an additional field, which older clients could ignore, but newer clients MUST use to allow for differentiation, -- OR -- a change in object version number.
-
-Because there are multiple datetime fields possible in any object, and additional use of such structures is conceivable in the future, such an additional field had to be introduced in a nested structure. Making its usage mandatory to gain certainty of whether an object was written by a new client seemed to add cruft without much benefit. A version change on the other hand would break older clients entirely, likely resulting in error messages or "disappearing" events for the user.
-
-Both approaches would logically favour a "fix broken objects when you see them" policy, which is much more demanding and burdensome for client implementors, and more error prone than the "lazy update" path described above, which relies on the user to identify unwanted behaviour and then make a decision about how to "fix" the event.
-
-== Notes for client implementors ==
+=== Notes for client implementors ===
There may be future use cases for time zone storage and DST calculations, such as other Kolab object types.
@@ -96,7 +86,7 @@ For events, which are the primary use case of this particular use case, there ar
{{note|Calculating Offset|It is recommended that the offset be calculated by performing the operation of (Summer time) - (Standard time) as there is apparently no guarantee this is always one hour, and can in fact be 30 minutes, e.g. on Lord Howe Island.}}
-== Description of current client behaviour ==
+== Description of current client behaviour / the issue ==
Existing clients currently make the implicit assumption that the time was specified in and should be calculated against the local time zone of the client itself. This will lead to issues when a user is changing time zones, or when participants in multiple time zones are concerned. This behaviour could be confirmed with both Kontact and the Kolab Web Client Horde.
@@ -106,6 +96,40 @@ KDE Kontact however incorrectly displays the meeting as scheduled for 11:00. The
Which other clients exhibit the same behaviour is unclear, but it seems there is no reasonable assumption that current behaviour correctly models any rational use case.
+== Background notes on design decisions & backwards compatibility ==
+
+This modification represents the least invasive change to redress the existing issues in the most sustainable way. This section seeks to explain why.
+
+=== Usage of RFC3339 ===
+
+There is already inconsistency between what the specification gives, and what the reference clients write in some datetime fields, e.g. last-modification. All clients write RFC3339 compliant datetime fields today. This likely results from usage of the system functions which are themselves RFC3339 compliant by these clients.
+
+While the Kolab specific format specifies a subset of RFC3339, it is not clear what is gained by restricting the format to this special case. Changing the specification to match client behaviour would rather document the existing situation. Because the output of older clients is fully compliant with RFC3339 already, no change is needed by client implementors in any function that writes datetime fields. Only where clients have written their own parsers for datetime, which consequently would be unable to read some datetime fields written by existing clients, would there be a need to retire that code, and use the system libraries instead.
+
+In summary: This change is not a change, but an adjustment to existing practice by explicitly referring to the widely used common standard for such datetime stamps.
+
+=== Usage of the Olson database ===
+
+The fundamental problem of DST handling is one where technical systems need to conform to human policy making updates. So all solutions are likely to bring their own imperfections. For the following reasons use of the Olson database is likely the most sustainable approach keeping future updates in mind.
+
+The alternative is to store DST data in the events themselves. This gives all clients the same information to work with, which is good, but it also makes sure that when DST rules change, all clients will be wrong. Usage of a system database brings the advantage that such updates in policy can be dynamically addressed and factored into the calculation without any need for user interaction. The downside of this would be that a client with an outdated database might display the time incorrectly.
+
+The second case is slightly better because it is closer to what a user is likely to perceive as logically consistent behaviour. Where the local database is out of touch with reality, '''all''' programs and the system time are likely to be off by the same amount, which is the DST interval. A user would then have a logical explanation for the problem that would not involve suspecting failure of the Kolab Groupware Solution.
+
+Usage of a database is also inevitable to keep the allowed selections synchronized between clients, ensuring a consistent user experience. While there is no officially recognized database that all applications refer to, the Olson database comes closest to being such a database, and the Olson timezone IDs are also used 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.
+
+=== How to retain backward compatibility and allow for smooth transition ===
+
+The best would be if the change could take place without notice by the user.
+
+This only becomes possible if clients have the chance to differentiate between objects according to the format prior to this update, and those afterwards. It would therefore require either an additional field, which older clients could ignore, but newer clients MUST use to allow for differentiation, -- OR -- a change in object version number.
+
+Because there are multiple datetime fields possible in any object, and additional use of such structures is conceivable in the future, such an additional field had to be introduced in a nested structure. Making its usage mandatory to gain certainty of whether an object was written by a new client seemed to add cruft without much benefit. A version change on the other hand would break older clients entirely, likely resulting in error messages or "disappearing" events for the user.
+
+Both approaches would logically favour a "fix broken objects when you see them" policy, which is much more demanding and burdensome for client implementors, and more error prone than the "lazy update" path described above, which relies on the user to identify unwanted behaviour and then make a decision about how to "fix" the event.
+
== References ==
{{Reflist}}