[Kolab-devel] KEP 2: Modification of datetime type, introduction of 'tz' sub-tag

[Gunnar Wrobel]

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
>> Systems):
>>> 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.
>> Hi,
>>
>> 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
>>
>> Hendrik
>>
>>
>>> 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  
converting them.

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.

Cheers,

Gunnar

> How makes Google Calendar ? this is UTC too
>
> Alain
>> _______________________________________________
>> Kolab-format mailing list
>> Kolab-format at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-format
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format
>



--
Gunnar Wrobel
Developer, Kolab Systems AG

e: wrobel at kolabsys.com
t: +49 700 6245 0000
w: http://www.kolabsys.com

pgp: 9703 43BE

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.