UPDATE: KEP 2: Modification of datetime: store local time, add 'tz' attribute (revision #10743)

[Jeroen van Meeuwen (Kolab Systems)]

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>