KEP #2: datetime RFC3339 and ISO 8601 and requirement of tz

[Bernhard Reiter]

Georg,

Am Montag, 28. Februar 2011 13:46:46 schrieb Georg C. F. Greve:
> Let me try to point you to some of the results, as most of these have been
> discussed at great length already and laid to rest long before:

sorry for dragging this out, but I'd rather have a longer process
on the first real KEP than a bad one that haunts us for a while.

[1]
> On Sunday 27 February 2011 18.12:37 Bernhard Reiter wrote:
> > Personally I object to the requirement to parse datetime according to RFC
> > 3339 and the wished capability to parse datetime fields by ISO 8601.
> > Rational: I did not read a compelling reason to do so.
>
> This is the simplest way of storing local time in a way that is both
> compliant with existing standards and backwards compatible with the old
> storage format.

For a thing as simple as storing values like YYYY-MM-DDTHH:MM:SS[.SS][Z]
exactely this seems sufficient and most simple.

I believe RFC 3339 and ISO 8601 is overkill. They are definately not simple.
The testsuite would be significant to cover everything. Since last time I've 
looked at this section "ISO 8601" was added as a wish. Also it was seen that 
RFC 3339 complicated the KEP because of the missleading "-0800" stuff that is 
possible with RFC 3339. RFC 3339 also is not a widely used "standard", it is 
only referenced by a smaller number of RFCs. 

Maybe others can give their thoughts here as well:
What do you think is simpler to savely implement
  RFC 3339 or YYYY-MM-DDTHH:MM:SS[.SS][Z]?

(Both have extra rules for the tz id, but in case of RFC 3339 the +-0800 
part has to be ignored, I am not sure all standard RFC 3339 function do this.)

> This would appear to be a new, standards-incompliant datetime format that
> only Kolab uses, with major potential for confusion and misinterpretation,
> because it would look like RFC3339 / UTC.

I don't think there is a lot to be missunderstood about
<start-date tz="Europe/Brussels">2001-06-19T11:01:23</start-date>

as opposed to <start-date 
tz="America/Los_Angeles">2005-12-19T02:55:23-08:00</start-date>
where the code has to ignore the "-08:00".

> It has been discussed before, but several people, myself included, felt
> this was asking for trouble and not a very robust choice.

Please explain this in further detail. Personally I can implement
my suggestion quite easily, but RFC 3339 or even ISO 8601 is something where
I never can be sure a used function does what I want and the test suite
is one or two magnitude larger.

[2]
> > I object to the requirement that all clients must store _all_ datetime
> > fields in the authoritative time zone. For many datetime fieldd, like the
> > last modification or creation, UTC would be enough and even slightly
> > prefered in my view. Suggestion: Change this to MAY or give a better
> > reason.
>
> It will have to be mandatory for at least the user-determined fields,
> because that is the only way to ensure storage of user preference. So we'll
> have to make a list of which fields MUST be in the authoritative time zone,
> and which fields MAY be in the authoritative time zone.

I do not think that we have to force to save user preference.
Often it does not matter.

> This is a complication that I'd rather have avoided, also because it seemed
> unnecessary. Storage of authoritative time zone in all items increases
> human readability, as users don't have to try to calculate local times from
> UTC.

I would not force it, because for some kolab objects or fields the old format 
is just enough. If you do not force it, there is no complication of the KEP.

[3]
> > I object to makeing it a requirement in the "notes for client
> > implementors" for clients to default to the stored time zone in all
> > cases. [...] Otherwise it might force the user interface to display the
> > time zone in simple cases as well and thus become a nuisance for the user
> > interface.
>
> The KEP says that where the time zone can be edited it has to default to
> what the user selected, not that time zone selection has to be added to
> every single occurence of a datetime field.

Okay. Maybe that is a phrasing issue it reads now
"Clients MUST default to the information in the stored time zone when opening 
an event for editing, as otherwise the recurrence calculation based upon it 
might be inadvertently altered by the user."

This means if I open up an single instance event, which was stored as 
Europe/Berlin even when being in Korea, I have to switch to Korea timezone
in the display. I believe this is wrong. The editor should display the time in 
Korean timezone. Maybe it can display that this was done in Europe/Berlin, 
and even keep it, but I would not recommend it for clients in all situations.

> Consistent client behaviour along the expectations of the user can only be
> achieved if all clients behave consistently, and thus a "must" form is
> chosen.

I know that Outlook plugins cannot change the user interface of Outlook 
easily and they cannot change some parts at all. Could be impossible to 
implement for them.
Kontact Touch currently also does not display the timezone information 
in the contact editor. So it could not support KEP2 without a significant 
interface change. 

> > Reading the description of the issue I believe the described "ambiguity"
> > between UTC and a local time is misslabled. The mapping between a single
> > UTC datetime and a localtime is bi-directional as far as I can tell. So
> > it is well defined and not ambiguous.
>
> The mapping of local time to UTC and the other way around is a function of
> several parameters: location, the respective date, and (past and future)
> political decisions about daylight savings time.
>
> If all three are perfectly well known, the relationship can be
> de-ambiguified.
>
> Otherwise you have no way of knowing whether 10:00 UTC is 11:00 or 12:00 in
> Osnabrück, or whether 11:00 in Osnabrück is 09:00 UTC or 10:00 UTC.
>
> When one thing can mean two or more other things, my understanding of the
> English lanugage is that that is called ambiguous.

It is only ambiguous under the assumption that the user always wants
to stay in the localtime timezone (which might be implicitely chosen)
even if this timezone definition changes. I agree that the user most of the 
time wants this, so it should be the default.
For technicians to understand it would be good to point this out.

> In any case, this seems more of an editorial than substantial remark, and I
> wonder whether that is really worth holding up the resolution of this issue
> now.

Correct it is an editorial remark.

> > Please give the precise Kontact version for the example in "Recurring
> > Events". The example cannot be fully reproduced and understood without
> > it.
>
> I've tried it with multiple versions, which all showed the same behaviour,
> and also got reports from customers of the enterprise 3.5 version that it
> shows this behaviour. Because the old format as an actual bug and cannot
> map this case properly, that is to be expected.

(Also an editorial remark.)
I've never seen a recommended Kontact e35 to put up reminders
at a different time where it is displaying the events. (Maybe I should try 
again and you've found a defect.)

> So the question now is: Does the above answer your questions, or do you
> want to maintain sustained opposition on any of the points above?

I am still not convinced about the three points I have objected to [1][2][3].
They would make life harder for Kontact implementors like me and possible 
other client implementors, if they try to adhere to the spec precisely. 

Also I do not remember clear preferences for these points from other
relevent client developers.

Best,
Bernhard
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110228/d8598e5a/attachment.sig>