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

Till Adam till.adam at kdab.com
Tue Mar 1 18:44:34 CET 2011


On Tuesday 01 March 2011 18:01:36 Bernhard Reiter wrote:
> Am Dienstag, 1. März 2011 09:21:09 schrieb Till Adam:
> > On Monday 28 February 2011 15:15:13 Bernhard Reiter wrote:

> > > 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.
> > 
> > As Georg points out, no one wants to implement _any_ date format
> > themselves, all platforms provide workable implementations, which
> > interoperate.
> 
> For reading you are right, you would want a library function,
> but writing it does not matter. Checking correctnees would not that
> easy to check of course, but this is of lesser importance.
> 
> BTW:
> http://doc.qt.nokia.com/latest/qdatetime.html#details
> does not say anything about RFC3339 for instance, only about ISODate.
> This probably is why the QMailTimeStamp implementation from Qt
> labs/messagingframe work uses
> else if (format == QMailTimeStamp::Rfc3339) {
>        result = QString( originalTime.toString( "yyyy-MM-ddThh:mm:ss%1" ) );
> result = result.arg( utcOffset == 0 ? QString("Z") :
> QString().sprintf( "%+.2d:%.2d", hOffset, mOffset ) );
> (They claim they cannot use QDateTime for localisation reasons.)

They are not using QDateTime's localized day and month names, that's unrelated 
to this discussion. And they are writing out the offset you find so confusing, 
which implementors of KEP2 could, but do not have to do. QDateTime can parse 
either, if it couldn't, the code in QMailTimeStamp wouldn't work. They simply 
chose to extend QDateTime's string serialization here, for reasons that I 
don't know. Probably because Qt (unlike KDE) does not support proper 
timezones, and this is the only way to come close. For Kontact, we could still 
use it for both reading and writing, as far as I can see.

> Not all variants of RFC3339 make sense to have in the storage.
> 
> I'd rather force writing of one variant of RFC3339 (which I gave)
> and add a "to make implementation easier clients MAY use a system function
> call for reading the datetime field and accept all sensible values."

I'm still not conviced the extra constraint pays off, but I'm not strongly 
opposed to adding a suggestion about the prefered serialization.

> > > > > 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.
> > 
> > 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.
> 
> What arguments convinced you? They should be in the proposal.
> 
> > The implementation cost is in the area of hours.
> 
> This is not the only cost, though.
> 
> For contacts, where we have mainly datetime from the past, this update
> forces new clients everwhere just for a little bit more of consistency.
> Otherwise new client could just write the old format.
> 
> Background: The UTC to local time mapping is only unsafe for the future,
> it is save for the past, as DST and timezone definitions cannot change
> anymore.
> 
> So forcing a change as a requirement for all datetime objects in all Kolab
> objects has the advantage of being more consistent, but also drawbacks. For
> last-change values there is no extra gain in having the local time zone. It
> is harder to read, as it needs two translations when the local time given is
> not mine: Local time new sealand -> UTC -> Local Time Germany. And it
> forces data updates at least at write time.

As soon as any field requires it, we need to implement that conversion anyhow, 
and our platforms already provide it, nearly everywhere. The user doesn't see 
the timezones where it makes sense, and the machines do not care, they simply 
consistently call the same date management method everywhere. Less code, 
cleaner code, easier to write, easier to maintain, no special cases. I don't 
think there is a need to change existing objects, unless they are written out 
anyhow. If they are written out anyhow, because of some semantic change, 
writing out a few more fields is of no concern. All implementations I'm aware 
of replace the full mime attachment anyhow for every write, so there's no 
performance difference, or implementational overhead. 

> > 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 ;).
> 
> Just from the interface design, I am not sure the interface you are thinking
> of here, it is the ideal solution. I'd welcome a KEP that leaves a bit more
> freedom here to desing a better interface which somehow tracks where in
> which timezone the user is. Of course this has to be entered somewhere, but
> maybe not directly at the event editor.
> 
> > > 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.
> 
> I agree that we as Kontact implementors were consulted. I'd rather not have
> dragged this out, but as I wrote before, new insights and thoughts were
> coming in the last days and this is what we have a comment period for.
> Thus I reread the KEP in order to just agree with it.
> 
> There are some passages with could benefit from a better phrasing, but this
> is editorial, so if there are no other changes coming out of the
> substaintial discussion we might just leave them be to not pour more time
> in.

Agreed.

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