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

Till Adam till.adam at kdab.com
Tue Mar 1 09:21:09 CET 2011


On Monday 28 February 2011 15:15:13 Bernhard Reiter wrote:
> 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.

I don't think it's fair to call it bad. There was also ample time to comment 
and give input, I have to agree with Georg here.

> [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]?

RFC 3339, because we can rely on platform implementations. QDateTime 
implements it, and we actually have to do more work, currently, to comply with 
the spec as it stands. 

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

As Georg points out, no one wants to implement _any_ date format themselves, 
all platforms provide workable implementations, which interoperate.
 
> > > 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.

I had the same objection, since adding the must requirement for all fields 
means adjustments to the Kontact implementation, but was convinced that it's 
cleaner and clearer to add it everywhere. The implementation cost is in the 
area of hours. 

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

Misunderstanding, I think, that's not what it says. See Georg's follow up to 
this question.

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

It's not relevant in the contact editor. In the events editor it is also not 
displayed, atm, but that's at explicit request of our German, non-travelling 
customer, for that project. The absence of this has bitten me personally on 2 
occasions, and I'll add it, if only to scratch my own itch ;).
 
> > > 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.

Bernhard, we, the Kontact implementors, were consulted in this process and 
gave our input, objections and judgement months ago. The KEP incorporates our 
feelings on the matter.
 
Till

Till Adam | till.adam at kdab.com | Managing Director Germany
KDAB (Deutschland) GmbH & Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions




More information about the format mailing list