Basic rationale of the KEP #2 design

[Hendrik Helwich]

Hello Georg,

Am Freitag, 11. März 2011 20:30:56 schrieb Georg C. F. Greve:
> [..]
> On Friday 11 March 2011 16.41:08 Florian v. Samson wrote:
> > [..]
> > Yes we do.  Any of us needed some time to fully comprehend the various
> > aspects and depth of the timezone issue.  Sure, that applies to Henrick
> > as well, and it was RFC3339 limited to UTC only: please do read his mail
> > you referenced.
>
> I did. Quoting from
>
>  http://kolab.org/pipermail/kolab-format/2010-December/001180.html
>
> sent by Hendrik on 21 December 2010:
>
>  "I think storing in local time would be the best solution.
>   If we look at this article:
>   http://www.worldtimezone.com/dst_news/dst_news_turkey02.html
>   It shows that it is in fact possible that the standard time somewhere
> might change.
>   So it is not enough to store the UTC time and a flag for DST to calculate
> the intended local time. It is needed to store the offset to UTC that was
> active at this time.
>   As i looked at RFC3339 i see that its not true that only UTC is possible.
>   Also local times like this are possible:
>
> 	2002-10-02T10:00:00+05:00
>
>  Perhaps this is a solution with which all are satisfied?"
>
> > Sorry, that is not true: the proposal for RFC3339 came from you.
>
> Please re-read the above.

i think Florian is right here. The proposal for RFC3339 came from you [1].
I always argumented against RFC3339 because i think it does not fit the Kolab 
needs very well. This is because it holds partial time zone information 
(utc offset) and this is not needed in Kolab XML (because full Timezone 
information will be stored). So we will have a redundancy which could always 
be a source of misunderstandings.

The above statement from me is taken from a discussion where i tried to 
convince you that it is needed to store local times in the Kolab XML. RFC3339 
was strongly preferred by you and i wanted to propose a compromise to end 
the time consuming discussion. The usage of local time instead of UTC time for 
start/end dates was the more important issue for me.

I still think the usage of RFC3339 holds mostly disadvantages:
* the specification gets unnecessarily complex because of the many possible 
  time formats of RFC3339
* the redundant UTC offset could be a source of misunderstandings
* implementation gets unnecessarily complex if no library is available

As said before i would just omit the UTC offset in the time format e.g. 
2002-10-02T10:00:00 for a local time (and 2002-10-02T10:00:00Z for UTC time).

I would like to propose again to create an XML schema to validate the Kolab 
XML. It would be extremely useful if this could be added to the KEP2 
document. The validity of Kolab-XML could automatically be tested easily. 
I recently used the Kolab Relax NG schema (from the kolab repository) and 
found that the output of Kontact and Toltec is not valid after that. This is 
probably already a known issue and the schema is out of date.

The time format could also be defined by a simple regular expression in the 
XML schema. So there would be a short clear and automatically testable 
definition instead of the long, complex, redundant and ambiguous definition 
of a RFC3339 local time (with timezone).

Best regards,

Hendrik


[1] http://kolab.org/pipermail/kolab-format/2010-November/001036.html

> [..]