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

[Hendrik Helwich]

Hi Georg,

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

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:

2004-05-04T15:00:00

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 
needed?

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

So in fact i think we have to do a trade-off here and decide what is more 
important:
(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 
all people.

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

Best regards

Hendrik