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

Georg C. F. Greve greve at kolabsys.com
Fri Dec 24 14:20:26 CET 2010


Hi Jeroen,

On Friday 24 December 2010 13.05:25 Jeroen van Meeuwen (Kolab Systems) wrote:
> 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; [...]

Yes, this possibility exists.

It is however possible for clients to recover from it with fairly low 
overhead, and still maintain the initial intent of the user. That possibility 
does not exist for any of the other proposals, they just fail without the 
client being able to detect their failure.


> ** the +0200 stores information that is duplicate, [...] Note this would
> render Kolab XML incompatible with RFC 3339

Yes. The introduction of a new format for storing time was considered.

The question is what creates more confusion:

A format that has some duplicity that will normally be correct, but with a 
clear path as to what is authoritative, --- OR --- a format that looks much 
like another, but isn't actually compatible.

The latter was what Hendrik and I considered more problematic. But if a lot of 
people feel we should grow our own format, we could consider that.


> 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.

That is what it does right now, although only in the implementor notes.

Maybe that should also go into the definition section.


> Also, since tz="" currently seems to be an optional attribute, 

Actually it is mandatory for all date/time stamps in the future.

So a correct field will always have explicit "UTC", or a geo-tz-id.


> 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

Not quite, actually. 

For date/time stamps like creation-date and such, tz information is not all 
that useful, and likely correct, as it is about the now and the past. So for 
those the tz attribute might be safely left away, butients must them treat 
that as UTC.

And it will also ensure that older data sets can still be correctly intepreted 
during the transition period.


> 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 version increment is something that could definitely be adjusted. I know 
Bernhard would like to use "2.1", so you'd already be on the same page there.

And yes. We should make a KEP on the version checking.

And as mentioned in the KEP, another KEP on how clients that find badly written 
entries should behave is also planned.


> 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.

So you're saying that

  "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. "

should become a

  "When adding new objects, clients MUST 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. "

Why would you want to exclude the possibility that a company sets one 
authoritative time zone by default, e.g. the company headquarters location?

Also, as you correctly described, there are substantial client-side 
complications for server-side clients from such a requirement.

Which benefits outweigh this?


> 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.

Yes. The accuracy of this information is always important.

This was the point we discussed at great length under the "Olson vs static 
time zone encoding" heading, with the end result that Olson in the end was 
considered the better choice for all the various reasons discussed and 
summarized to some extent in the KEP.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101224/008d360f/attachment.sig>


More information about the format mailing list