KEP 2: Modification of datetime type, introduction of 'tz' sub-tag

Georg C. F. Greve greve at kolabsys.com
Mon Nov 29 19:24:14 CET 2010


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

If they have been using a different function, it should be basically a matter 
of searching & replacing that function against the one that does RFC3339.


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


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

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.

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.

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.

Hard-coding this into the format now just creates legacy we need to worry 
about transitioning from in the future.


> You will get bug reports all the time and it will be very hard to debug
> this kind of problems and to solve them because this is fixed by the
> design of the kolöab format.

The phenotype here will be that one person will have missed a recurring event 
because their client wrongly displayed it.

The support cheat sheet for this will contain the question "Were you the only 
one missing it? How old is the system?" the answers to which will greatly 
narrow down the possibilities.

A fix for the issue will consist of updating the systems database, and provide 
a good explanation to the customer regarding the root cause of the issue of 
what went wrong that won't undermine their future confidence in Kolab.

Being the "last line of support" for many Kolab issues I haven't seen any 
concerns from our technical staff about this, to be honest.


> You misunderstand my motivation.

That is always possible.

I can only speak for my motivation, which in all of this has been to try and 
help you by moving this forward quickly so you can get reliable information 
before your project ends, since I'd really like to help your project succeed.


> I just have to work with the kolab format for a project.

I understand that. But we have to work substantially longer with it than just 
one project, and for quite a few more participants. So our thinking needs to 
be focused on the long-term benefits, and the avoidance of future legacy.

In other words: I don't want to take the seemingly easy path now and later 
realize that everyone has to change their client again because we failed to 
understand and anticipate future needs and developments properly.

You have your particular view on the issue, which is entirely fine.

But please understand that over the past weeks there have been plenty of 
discussions about this, with a very diverse set of opinions and points.

From memory and without wanting to have to go through weeks of archive, I 
understood there to be at least:

 * 2 people saying that KEP 2 was unnecessary, and should be scrapped;
 * 3 or more people speaking out for the database, but of them;
 * 1 person seeming to prefer the Windows specific database;
 * 2 people strongly advocated RFC3339;
 * 1 person saying they had certain gut feelings, but needed more time;
 * 1 person reporting off-list they like RFC3339 and database;
 * 1 person strongly arguing against both.

But of course I'll have forgotten someone. The point remains that trying to 
take all of this into account and do it justice is not exactly trivial.

So it is less than helpful to stand up and say "everyone now do as I said 
because there is a majority for my position" when the discussion is slowly 
moving towards a deeper understanding of the issue, as it sets the discussion 
back and delays the decision finding, which you were asking to speed up before.

That is what I tried to express in my mail.

But if you now feel we should spend more time to discuss this some more, then 
that is what we'll have to do.

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/20101129/548e2c64/attachment.sig>


More information about the format mailing list