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

Alain Abbas alain.abbas at libertech.fr
Wed Nov 17 17:00:13 CET 2010

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 ..
How makes Google Calendar ? this is UTC too

> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

More information about the format mailing list