[Kolab-devel] KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
wrobel at kolabsys.com
Tue Nov 23 15:38:19 CET 2010
Zitat von Alain Abbas <alain.abbas at libertech.fr>:
> Le 17/11/2010 16:40, Jerry Pommer a écrit :
>> ------ Original Message ------
>> From: Hendrik Helwich<h.helwich at tarent.de>
>> Date: Wednesday, November 17th, 2010 9:28 AM CST
>> To: "Jeroen van Meeuwen (Kolab Systems)"<vanmeeuwen at kolabsys.com>
>> Subject: Re: [Kolab-devel] KEP 2: Modification of datetime
>> type, introduction of 'tz' sub-tag
>> Am Mittwoch, 17. November 2010 16:03:15 schrieb Jeroen van Meeuwen (Kolab
>>> On Wednesday, November 17, 2010 01:58:08 pm Georg C. F. Greve wrote:
>>>> So it is an inconsistency, and a reason why I believe we should link this
>>>> to the RFC that everyone else is using for this purpose, as all the
>>>> operating systems that are network capable have built-in functions to
>>>> read and write this format.
>>> I would argue this (the alteration of valid datetime notations) would need
>>> to become a separate KEP, as it has to set rules on how clients should,
>>> must or may preserve the original format.
>> Why not keep the established UTC time format like it is defined in the kolab
>> specification? It holds all needed information and it would not be necessary
>> to adapt the kolab specification on that point.
>> Best regards
>>> Kind regards,
>>> Jeroen van Meeuwen
>> I strongly disagree with this proposal. Creating events in local
>> time adds unneeded complexity when working with recurring events
>> shared amongst users in different timezones. UTC is the constant,
>> and every client knows what their offset is (or will be) at the
>> time of the event. Why should I concern myself with the local time
>> of the user that created the event, if we all convert from UTC and
>> end up on the phone at the same time no matter where we are? I've
>> just been through this with iCal, and it really is awful.
>> If someone can present a test case in which such additional effort
>> is necessary, I'm willing to learn from it if there is something
>> that I'm missing. Why?
>> Jerry Pommer
>> jpommer at bynari.net
> Completely agree with you Jerry , all clients normally know the timezone
> and know the offset and generally all spec are in UTC (example
> activesync) . The Iphone Even when you change of time zone (exemple when
> i travel from france to England) display the time in
> the current timezone.
> For my part Z-push/Backend knows only UTC .
> that means if this format is adopted tha i must convert Tz-> UTC all
> the events with all the complexity ..
Definitely not as you are using Kolab_Format. It is the job of
Kolab_Format to provide you with a consistent API as much as possible.
So you'd still get all dates in UTC. The library would have the job of
The only thing you'd see as a result from the format change would be
additional information in the recurrence part. That would contain
timezone information. At least that is my current plan.
> How makes Google Calendar ? this is UTC too
>> Kolab-format mailing list
>> Kolab-format at kolab.org
> Kolab-format mailing list
> Kolab-format at kolab.org
Developer, Kolab Systems AG
e: wrobel at kolabsys.com
t: +49 700 6245 0000
pgp: 9703 43BE
This message was sent using IMP, the Internet Messaging Program.
More information about the format