UPDATE: KEP 2: Modification of datetime: store local time, add 'tz' attribute (revision #10743)
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Fri Dec 24 13:05:25 CET 2010
Georg C. F. Greve wrote:
> Hi all,
>
Hi Georg,
Despite my more general concerns using local datetime stamps, I suppose my
primary concerns relevant to using the local time as is currently proposed by
KEP #2 are, given the following example scenario;
* Client A creates an appointment for June 3rd 2014, 13:00, and sets
authoritative timezone to Europe/Berlin (e.g. reservation for meeting room
physically located in Berlin or similar),
* Hypothetically, DST rules change for Germany as per 2013,
* The kolab.xml would still contain a start-datetime 2014-03-03 T 13:00:00
+0200 in a start-datetime with the tz attribute set to "Europe/Berlin" as the
authoritative timezone.
The stored datetime;
** would now be invalid to Olson (e.g. there is no +0200 for Europe/Berlin in
2014 any longer),
** the +0200 stores information that is duplicate, irrelevant and an open
invitation to overall confusion. If the local time is to be used for the
storage layer, then storing the information that is effectively the dynamic
offset to UTC at one point in time (and subject to change) should be
prohibited or ignored during any parsing efforts, and the dynamic offset to be
used should instead be calculated in the presentation layer, using a start-
datetime in Zulu notation (e.g. no offset is to be included) along with the
authoritative tz="" information. Note this would render Kolab XML incompatible
with RFC 3339 -not a loss compared to the current situation- as not storing
UTC but also not appropriately using the offset in the notation is
bastardizing the notation formats described in RFC 3339.
Alternatively, clients could be told the tz="" attribute is authoritative and
any offset stored in an RFC 3339 datetime notation not Zulu is to be ignored
at all times.
Also, since tz="" currently seems to be an optional attribute, no tz=""
information having been stored within the event would need to be interpreted
as if the datetime is in UTC.
That said, just to cover such situations and avoid creating prone to error
parsing, I would strongly recommend tz="" becomes a mandatory attribute.
The former is mutually exclusive with the third MUST in the first bullet point
in the comment on "Event time calculation" for the current draft of KEP #2
(line 100 in the KEP source txt file as of revision
9757b2a5b16ca7a741bebfb33c67917c282f53d6), which I suppose can be rephrased to
reflect -the aforementioned considerations and upcoming outcome
notwithstanding- that the "and the value of the time stored in the datetime
field MUST" is not included in the same clause that starts with "Otherwise
(...)".
The former notwithstanding, any of such would break any backwards
compatibility with client logic implemented based on a former version of the
Kolab XML format, -they will not be able to parse the new format correctly- as
would the current proposal unless a clause is provided "no tz info means UTC"
-but still the new format would be magic written in Chinese to many existing
clients. Such would, normally, constitute a major bump in the versioning of
the standard, but regrettably clients do not seem to have Kolab XML version-
based parsing implemented at all.
The former seems to have been a primary motivator to work out a proposal based
on using UTC (as is currently in place but lacks the additional features
sought to be implemented through this KEP originally) + (optional, to cases
where it applies) authoritative tz information. While it had appeared to me as
majorly important to many before, it seems to have been ignored completely
now.
I suppose that, therefore, the (or "a") KEP will need to include statements on
client implementations starting to interpret the version attribute to a
kolab.xml parent tag (e.g. <event version="1.0">), the version attribute is
correctly and consequently updated according to the canonical locations of
both these KEPs and the authoritative Kolab XML specification documents
versioning, proper versioning practices are put in place (e.g. version major
vs. minor component bumps), this KEP and future format related KEPs include a
proposed consequential versioning bump, and all describe how clients not
compatible with the newer format MUST or MAY handle the newer format -whatever
is deemed appropriate for any given future change. I suppose a new KEP in
itself could describe which MUSTs and MAYs are acceptable ("don't ask, don't
tell" vs. "look, but don't touch" vs. "convert automatically" vs. "convert
interactively" vs. "convert by server batch-job" vs. etc. etc.)
Additionally, it may be valuable to require (through the KEP currently under
review) the client implementation to take the local user system's timezone as
authoritative by default, in cases where it has not been implemented as such
already. This applies to both web applications that will require the browser
timezone information as exposed and available through JavaScript, or to a
local system application per through the system / user settings. Most notably,
however, is how client implementations remotely connected over Terminal
Services and most notably those connected to remote services hosted in other
then the client native timezones are supposed to handle the concept of the
"user local timezone".
Having said that, using the local time in the Kolab XML, the storage would
spell, for the occurence of the event, the event occurs at "whatever is the
client's equivalent representation of this exact time in this exact (other)
timezone, continuously" -e.g. a Brazil client would present the event at
whatever is his local representation of 13:00, Europe/Berlin. It'd be dead-on
accurate at all times, but it has two significant implications;
Note that the client is now dependent both on the accuracy of the information
it holds regarding what the Europe/Berlin timezone is doing, as well as
dependent on the accuracy of the information available regarding the client's
own timezone.
Also note that *users* will now need to learn how altering the timezone of an
event impacts that event. While this, using Kontact on the office desktop
computer day in day out does not seem to pose a problem at all, the proverbial
Internet Cafe on Holiday may default to that different timezone. I suppose
this is no different from the current situation, though I figured it'd be
worth mentioning anyways.
On an additional (side-)note, the server-side will need a similar equivalent
of additional processing to compare invitations against calendars to be able
to enforce the invitation acceptance policies.
Kind regards,
Jeroen van Meeuwen
--
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com
pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20101224/905c2125/attachment.html>
More information about the format
mailing list