summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeroen van Meeuwen (Kolab Systems) <vanmeeuwen@kolabsys.com>2010-12-24 13:24:59 (GMT)
committerJeroen van Meeuwen (Kolab Systems) <vanmeeuwen@kolabsys.com>2010-12-24 13:24:59 (GMT)
commit5193a33a4da4c5b99448adb5719f424b05668175 (patch)
treed60224ba5e73c223124e05c4af31cb4e7a672958
parent9757b2a5b16ca7a741bebfb33c67917c282f53d6 (diff)
downloadkeps-5193a33a4da4c5b99448adb5719f424b05668175.tar.gz
Touch up the wiki syntax of KEP-0002.
Links to sections are now actually links to sections, and RFC references have been corrected (the 2445 one). Also, RFC references now use the Template:Rfc as has been proposed through KEP #4. Additionally, a few typos have been corrected.
-rw-r--r--KEP-0002.txt29
1 files changed, 15 insertions, 14 deletions
diff --git a/KEP-0002.txt b/KEP-0002.txt
index 3c4d873..3e4f78f 100644
--- a/KEP-0002.txt
+++ b/KEP-0002.txt
@@ -13,7 +13,7 @@
__TOC__
== Abstract ==
-Kolab used to store all times in UTC and did not allow for time zone information. This was too simplistic an approach to solve the complex issues caused by time zones and their DST rules, as explained in the [#Description_of_the_issue background section] below.
+Kolab used to store all times in UTC and did not allow for time zone information. This was too simplistic an approach to solve the complex issues caused by time zones and their DST rules, as explained in the [[#Description_of_the_issue | background section]] below.
It is primarily two issues that are being addressed by this KEP, one essential and technical, the other related to usability. The usability related issue is that users sometimes specifically set time zones for datetime fields and expects this explicit selection to be preserved across sessions and clients. Without storage of this information clients cannot meet that user expectation.
@@ -25,7 +25,7 @@ Some reference for background was provided on the Kolab format list <ref name="k
== Update to the XML Format ==
-All objects hold datetime in the form of creation and modification times. Consistent time handling across all object types and occurences of time objects is highly desirable. The following change therefore affects all Kolab object types. It is part of the changeset for version 1.1 of all objects.
+All objects hold datetime in the form of creation and modification times. Consistent time handling across all object types and occurrences of time objects is highly desirable. The following change therefore affects all Kolab object types. It is part of the changeset for version 1.1 of all objects.
Change of type: '''datetime'''
@@ -34,17 +34,17 @@ The type for datetime storage in Kolab XML is modified as follows:
* Clients '''MUST''' store all datetime fields in their ''authoritative time zone'' as selected by the user when entering the date/time.
* The autoritative time zone '''MUST''' be one of 'UTC' (all caps) '''-- OR --''' geographical time zone identifiers in the uniform naming convention designed by Paul Eggert, specifying time zones from the Olson database, a.k.a. tz database, a.k.a. zoneinfo database <ref>[[wikipedia:Zoneinfo | Wikipedia: Zoneinfo]]</ref>.
* Where no authoritative time zone is provided, clients '''MUST''' consider 'UTC' authoritative.
-* All datetime fields '''MUST''' be formatted according to [[RFC:3339]]<ref name="rfc3339">[[RFC:3339]]: Date and Time on the Internet: Timestamps</ref>.
+* All datetime fields '''MUST''' be formatted according to {{rfc|3339}} <ref name="rfc3339">{{rfc|3339|title=Date and Time on the Internet: Timestamps}}</ref>.
* Where UTC is authoritative, clients '''MUST''' use the UTC based Zulu notation for datetime fields, so YYYY-MM-DDTHH:MM:SSZ with 'T' and 'Z' as the literal characters.
* All datetime storage fields '''MAY''' carry up to one 'tz' attribute describing the time zone in the uniform naming convention designed by Paul Eggert, specifying time zones from the Olson database, a.k.a. tz database, a.k.a. zoneinfo database <ref>[[wikipedia:Zoneinfo | Wikipedia: Zoneinfo]]</ref>.
* All fields that store future dates at the time of writing an entry, e.g. the 'start-date' and 'end-date' fields, '''MUST''' define the 'tz' attribute. Where the event should be calculated strictly against UTC, emulating previous behaviour, the value of the 'tz' field must be set to 'UTC' (all caps) explicitly.
-* All clients '''MUST''' be capable of parsing datetime fields according to [[RFC:3339]]<ref name="rfc3339">[[RFC:3339]]: Date and Time on the Internet: Timestamps</ref> format and '''SHOULD''' support loose parsing according to the superset provided by ISO 8601 <ref name="iso8601">ISO 8601: https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601</ref>.
+* All clients '''MUST''' be capable of parsing datetime fields according to {{rfc|3339}} <ref name="rfc3339">{{rfc|3339|title=Date and Time on the Internet: Timestamps}}</ref> format and '''SHOULD''' support loose parsing according to the superset provided by ISO 8601 <ref name="iso8601">ISO 8601: https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601</ref>.
It is recommended that all clients '''SHOULD''' check the Olson database at least once every three months against the locally cached version, '''OR''' suggest update policies for their respective operating systems that ensure the Olson database gets updated regularly. As far as is known, all commonly used and supported GNU/Linux distributions do this already.
=== Canonical client behaviour ===
-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. For more detail see [#Notes_for_client_implementors Notes for client implementors] below).
+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. For more detail see [[#Notes_for_client_implementors | Notes for client implementors]] below).
When tz is specified as 'UTC' or missing, a client '''MUST''' calculate recurrences strictly according to UTC.
@@ -70,7 +70,7 @@ Examples of valid 'start-date' fields using datetime structures according to the
=== Upgrade Path ===
-The previous datetime format used by Kolab XML formats up to and including version 1.0 based on strict UTC Zulu notation will continue to be understood and interpreted in the same way as was canonical behaviour before, although it is seems that at least some older clients did not implement canonical behaviour correctly (see [#Current_client_behaviour Current client behaviour], below). So newer clients confronted with an older data set should safely operate according to specification.
+The previous datetime format used by Kolab XML formats up to and including version 1.0 based on strict UTC Zulu notation will continue to be understood and interpreted in the same way as was canonical behaviour before, although it is seems that at least some older clients did not implement canonical behaviour correctly (see [[#Current_client_behaviour | Current client behaviour]], below). So newer clients confronted with an older data set should safely operate according to specification.
All clients must already preserve all tags and attributes they do not understand, but from discussion on the mailing list, not all clients properly guarantee this at the current point in time. So the newly introduced 'tz' attribute would be in peril of being stripped out by older clients.
@@ -91,7 +91,7 @@ There may be future use cases for time zone storage and DST calculations, such a
For events, which are the primary use case of this particular use case, there are two existing uses:
; '''Store user preference'''
-: A user typically has selected a time zone to enter a date/time. When storing without timezone information, that information is lost. So while the user might realistically expect the event to preserve the time zone they entered initially when edting it again, Kolab was unable to provide this functionality thus far.
+: A user typically has selected a time zone to enter a date/time. When storing without timezone information, that information is lost. So while the user might realistically expect the event to preserve the time zone they entered initially when editing it again, Kolab was unable to provide this functionality thus far.
:* Unless already required because the date/time field is in the future (see above), clients '''SHOULD''' therefore always store a user-selected time zone, e.g. when different from the default choice offered.
:* Clients '''MUST''' default to the information in the stored time zone when opening an event for editing, as otherwise the recurrence calculation based upon it might be inadvertently altered by the user.
@@ -147,10 +147,11 @@ The following are two examples of existing client behaviour prior to this KEP wh
The exception to the above is when the event has been placed sufficiently far into the future and lives within the weeks of DST regime flexibility.
Then the following can occur:
-: * Person A stores event for 11:00 Europe/Berlin three years into the future.
-: * The client looks up DST rules known at this time, correctly concludes this is still standard time, and stores 10:00 UTC.
-: * One year later, DST rules get changed, and propagated through the typical channels to all platforms.
-: * Two years later, the client looks up the event, knows that DST is in effect, and correctly translates 10:00 UTC to 12:00 local time in Europe/Berlin.
+
+:# Person A stores event for 11:00 Europe/Berlin three years into the future.
+:# The client looks up DST rules known at this time, correctly concludes this is still standard time, and stores 10:00 UTC.
+:# One year later, DST rules get changed, and propagated through the typical channels to all platforms.
+:# Two years later, the client looks up the event, knows that DST is in effect, and correctly translates 10:00 UTC to 12:00 local time in Europe/Berlin.
So in effect, the event which was set for 11:00 Europe/Berlin is now incorrectly displayed at 12:00 Europe/Berlin due to the time zone change. So correct behaviour on all sides can lead to incorrect results due to this ambiguity between UTC and local time. The other way to invoke this scenario would be to store an event with an older client on a platform with outdated DST rules and read the same event with a current client with current DST rules.
@@ -192,9 +193,9 @@ Thus storage of local time was understood to be the least complex solution to a
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. There were three suggestions under discussion.
-One was to store DST data at the time the event was created in the events themselves. This gives all clients the same information to work with, which is good. This is also the path taken by [[RFC:3339]]<ref name="rfc2445">[[RFC:2445]]: Internet Calendaring and Scheduling Core Object Specification (iCalendar)</ref> with the VTIMEZONE component, which allows to statically encode DST rules. Such static encoding does however ensure that when DST rules change, all clients will display the event wrong.
+One was to store DST data at the time the event was created in the events themselves. This gives all clients the same information to work with, which is good. This is also the path taken by {{rfc|2445}} <ref name="rfc2445">{{rfc|2445|title=Internet Calendaring and Scheduling Core Object Specification (iCalendar)}}</ref> with the VTIMEZONE component, which allows to statically encode DST rules. Such static encoding does however ensure that when DST rules change, all clients will display the event wrong.
-This is why reportedly various clients using iCalendar ignore the encoded static DST rules and instead rely upon the mandatory tzid field, often using the Olson database for lookup of the current DST rules, as that is also specifically mentioned in the VTIMEZONE section of RFC2445 as a good reference base for globally canonical time zone IDs.
+This is why reportedly various clients using iCalendar ignore the encoded static DST rules and instead rely upon the mandatory tzid field, often using the Olson database for lookup of the current DST rules, as that is also specifically mentioned in the VTIMEZONE section of {{rfc|2445}} <ref name="rfc2445">{{rfc|2445|title=Internet Calendaring and Scheduling Core Object Specification (iCalendar)}}</ref> as a good reference base for globally canonical time zone IDs.
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 if one of the relevant time zones was affected by an update that is not yet locally available, e.g. the client operating system has not been maintained for six months or more.
@@ -223,7 +224,7 @@ Usage of a database is also inevitable to keep the allowed time zone selections
Because 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.
-In order to support clients on non-Olson platforms, as well as all clients in their iTIP<ref name="rfc2446">[[RFC:2446 | RFC2446: iCalendar Transport-Independent Interoperability Protocol (iTIP)]]</ref> handling, Kolab Systems shall work with all client implementors to maintain and continue to make freely and publicly available a database to match various time zone ids to Olson database locations.
+In order to support clients on non-Olson platforms, as well as all clients in their iTIP <ref name="rfc2446">{{rfc|2446|title=iCalendar Transport-Independent Interoperability Protocol (iTIP)}}</ref> handling, Kolab Systems shall work with all client implementors to maintain and continue to make freely and publicly available a database to match various time zone ids to Olson database locations.
== References ==