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

[Georg C. F. Greve]

Bernhard,

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 that any point you raise if left unaddressed would turn this KEP 
into a bad one. The improvements that are now being discussed are incremental 
issues, not fundamental ones.

At the same time, we know the current format has an issue that has been 
haunting us and our users, and getting this KEP closed is prerequisite to 
fixing this defect.

So in my view it would have been preferrable if you had made your points 
during the half year where this draft was under discussion, or reacted to the 
reminders to provide input in the past months when the discussion had reached 
its end.

Be that as it may, the draft is now demoted back to discussion it seems.


> I believe RFC 3339 and ISO 8601 is overkill. They are definately not simple. 

RFC3339 is very close to what you propose.

In fact what you propose looks like an almost complete subset of RFC3339, so 
is likely to be misinterpreted as RFC3339. 


> Also it was seen that RFC 3339 complicated the KEP because of the
> missleading "-0800" stuff that is possible with RFC 3339. 

I'm not sure what is supposed to be misleading about that.

It seems clearly defined.


> RFC 3339 also is not a widely used "standard", it is only referenced by a
> smaller number of RFCs.

RFC 3339 is a subset of ISO 8601, AFAIK. I don't think it is a factually sound 
statement to say ISO 8601 is not a standard.  Any counting the use of RFC3339 
needs to include all references to ISO 8601, which to my knowledge is the most 
far spread open standard for datetime expression and the basis for most system 
libraries for datetime parsing and writing, but you are welcome to point out 
which format is more widely spread.

I'm still not sure that forcing all clients to write their own parsers from 
scratch is necessarily the best cause of action, but if the majority feels a 
new, proprietary datetime format is the way to go, then I will have to go 
along with that.


> Please explain this in further detail.

It's the fairly old "use system functions for standard tasks" vs "write 
everything yourself" debate with a hint of "not invented here" syndrome.

OpenOffice.org went down that route to a rather large extent, including for the 
windowing functions, and now have been struggling for years to recover from 
that. Personally I believe it makes sense to use system functions where 
possible to reduce the likelihood of errors and reduce memory footprint.

The system functions I saw so far seemed clearly oriented around ISO8601 and 
thus also RFC3339, so that is what seemed to make sense, as a bug in these 
functions would affect ALL applications on a system, and thus is likely to be 
fixed quickly.


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

I disagree.

If the user took the time to make that selection, I believe it matters.


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

That would be fine.


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

I believe this is a misunderstanding of what is written.

The above says that when it was stored as Europe/Berlin, it gets displayed as 
Europe/Berlin, regardless of where the user is at the time.

I believe that is the correct behaviour.


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

That is why so much time has been given to look into this issue.

Only the Outlook experts can answer this question: If Outlook stored an event 
as being in one time zone, and then edits it, which time zone is presented to 
the user in the editing dialogue?


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

Inability to deal with mobility seems a rather serious weakness in clients for 
mobile devices. 

Or are you talking about address book entry editing? I don't think that most 
clients allow users to set time zones for the dates that are being stored. So 
in that case the KEP is already met, as there is no user selection to be 
preserved.


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

No. Because there is ambiguity in both directions regardless of your primary 
reference frame. Translating from one to the other is ambiguous, and needs 
some additional data to de-ambiguify. Both local time and UTC have their use 
cases, we cannot disregard either, so we need to deal with the ambiguity.


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

One of your customers has. I'll give you details in private mail.

We know there is a defect in all clients, due to the limitations of the 
storage format we're addressing with KEP2. So yes, there is a defect in all 
clients including Kontact e35. Once KEP 2 is finished and implemented, that 
particular defect should no longer exist.


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

Because they preferred phone over email, we had a phone conference with Volker 
Krause, Till Adam and Allen Winter on the KEP last year.

To my knowledge all their recommendations and preferences have been taken into 
account in the current version of the KEP. The same is true for all other 
feedback by the Kontact developers, AFAIR.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110228/871ed88f/attachment.sig>