KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
h.helwich at tarent.de
Tue Nov 30 10:52:45 CET 2010
Am Montag, 29. November 2010 19:24:14 schrieb Georg C. F. Greve:
> Hi Hendrik,
> On Monday 29 November 2010 14.20:44 Hendrik Helwich wrote:
> > This comparison is not fitting very well, because there is no need to
> > implement a parser for the strict Zulu format. You have system libraries
> > for that in programming languages like C, Java, etc.
> In that case I seem to have misunderstood your point about the complexities
> of implementing a full RFC 3339 parser, whereas the old format would allow
> to create your own parser easily.
> I agree with you that using the system libraries for time stamp parsing is
> the right thing to do, which is why the switch to RFC 3339 should be fairly
> simple and robust, as all systems need to parse this format routinely all
> the time, and parsers for it exist on any internet capable device, as RFC
> 3339 is the RFC for Date & Time on the Internet.
> For a client implementor, it should normally mean no to little code change,
> depending on whether they were using the standard parsing functions to
> parse date and time in Kolab's XML, as those functions often support
> If they have been using a different function, it should be basically a
> matter of searching & replacing that function against the one that does
> > But using the strict Zulu format, clients which do not implement the KEP2
> > could still parse the new format correctly and display them correctly for
> > events without recurrence.
> As explained, the version of the event XML after applying KEP 2 will have
> to be 1.1, because as both Gunnar and Joon pointed out older clients *do*
> strip out unknown XML tags, despite what the specifications says.
> > This is another small pro for the strict Zulu format i would say
> It would be an advantage, yes.
> But that advantage can be had without the cost of foreclosing future
> integration of additional technologies, e.g. by specifying that for
> backward compatibility, clients SHOULD write in Zulu format for the current
> object types, for which Zulu is sufficient, but MUST be able to parse full
For backward compatibility i agree that clients should be able to read RFC3339
for the first koab format version. But for writing i think clients MUST write
a clear normailzed datetime format like the Zulu format and also do not need
to read RFC3339.
This is because i see no real benefit for kolab in the complex RFC3339
datetime format. You can have partially timezone information in that datetime
format. And there is no need for this information. Why not omit this unused
information to make the format more clear and remove redundancy?
If we have the possibility to change things in version 1.1 i would like to
pick up the idea of Andrew (Mail from 12.11.2010) to specify times directly
in local time e.g. for the element "last-modification-date" in the Zulu
format and for the element "start-date" optionally in a local time like this:
So the Suffix 'Z' could indicate that it is a UTC time. For a local time, the
timezone which is specified in the kolab format xml must be used.
This would have the advantage, that no redundancy in the timezone information
is possible (like it is with the RFC3339 datetime format) and this would lead
to a more clear datetime format in my opinion.
You suggested that the Zulu format could be not sufficient. I think you are
referring to the milliseconds. Do you see a use case where this could be
> > The kolab format specification should define how clients must calculate
> > the times which are shown to the user. If the timezone information is
> > included in the kolab format (like it is done in iClanedar) it can be
> > assured that all people see the correct times.
> No, actually. It cannot assure that. iCalendar has proven that already.
You are right. If the time zone data in the koab xml is outdated, the time
could be wrong. What i wanted to say was that all people would see the same
time which in my opinion is more important than that it follows time zone
So in fact i think we have to do a trade-off here and decide what is more
(a) to use actual time zone data
(b) to assure that all people come to the same time to a meeting
Additionally i think it could be allowed for clients to update the time zone
information in the kolab xml if they see that it is outdated. This could be a
compromise to allow both: actual time zone data and also the same times for
> There are several assumptions in the above statement that explain why.
> The first one is that clients will not be trying to keep their data
> consistent for the user when they notice that the information is outdated,
> and that different clients won't have different opinions about whether or
> not they know better.
In my opinion it should be part of the specification to determine how clients
should calculate the times. If they implement it in another way it will be a
bug. The specification should leave no space for own interpretations in this
Additionally it could be allowed for clients to update the timezone data in
the kolab item if they notice that its outdated.
> The only thing that is ensured by hard-encoding it into the object is that
> when the information becomes outdated, *all* clients will show *wrong*, but
> at least consistent information.
This i right. But in my opinion it is very important that all people see the
same time of the meeting. Otherwise somebody could miss it.
> Unless, of course, *some* clients notice that the information is outdated,
> and try to interpret what was meant, in which case you'll get completely
> disparate behaviour.
> > When using an external time zone database it cannot be assured that the
> > displayed times are correct.
> That can also not be assured by storing outdated information, see above.
> But the database approach already works very well for the vast majority of
> computers out there. I haven't heard people complaining that their computer
> somehow got confused about daylight saving time for some time now.
> And as long as they have *some* update of their machine within a 3-5 year
> window, that database should be kept sufficiently up to date.
> Also, as others have pointed out in this discussion: The Olson database is
> becoming more common, not less.
> So it will likely be supported by an NTP-like service to update DST
> information in the future, which will give us maximum reliability and
> assurance of correct display, with no change to the storage format.
To be honest i have doubts that this will work correctly in practice. All
people on all the different systems need to have always a database which is
fully mappable to Olson database and which also needs to be in the same
state. How can it be assured that all people always update their database at
the same time?
> Hard-coding this into the format now just creates legacy we need to worry
> about transitioning from in the future.
I am aware that at sometime this DST stuff will (hopefully :-) ) not be
needed any more and can be removed. But right now i see no other way to
assure that all people see the same start time of a meeting.
More information about the format