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

[Bernhard Reiter]

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

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

I did not call it "bad", I am lacking the good reasons at some points.

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

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

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

Ah, now I get it, I guess I was missreading the following sentence here
"Clients MUST store all datetime fields in their authoritative time zone as 
selected by the user when entering the date/time."

If that means "If a user explicitely selects a timezone when entering 
date/time, Clients MUST store the timezone within the corresponding datetime 
object", then yes, it would only be restricted to places where the user
can explicitely set this like the event start and end dates. 

(A system setting would also be selected "by the user", though not during the 
time of the date/time selection. If the "when" is related to the store, it 
gets the wrong meaning.)

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

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/20110301/c88532c7/attachment.sig>