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