KEP #2: datetime RFC3339 and ISO 8601 and requirement of tz
Georg C. F. Greve
greve at kolabsys.com
Mon Feb 28 17:15:39 CET 2011
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
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
> I do not think that we have to force to save user preference.
> Often it does not matter.
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
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
> 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.
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format