Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data




Am Dienstag, 5. Oktober 2010 10:20:30 schrieb Milan Crha:
> On Tue, 2010-10-05 at 10:00 +0200, Hendrik Helwich wrote:
> > I understand this point for recurring events. In the Kolab format it
> > is only allowed to store time data in UTC format (see 1.2.1 in [1]).
> > So we have to think how we can handle this problem in our software.
>
> 	Hi,
> aha, pity they do not support any timezone, though I understand it's
> easier for them to understand only UTC and nothing else. Try whether you
> are able to store your own elements in the XML on the server, and if so,
> then I would add there a location of the timezone user used for the
> event, and when parsing back from XML then convert times to that
> timezone too. If they'll reject your own elements, then it'll be bad and
> you would have no option to keep user's timezone on component.

Hi,
it is possible to store your own data in the kolab format [1] (Your own XML 
Tags and binary mail attachments). So we could preserve the timezone 
information from evolution iCalendar.
But we still have the problem then that the time in some recurring events 
could be shown different in kontact and evolution in winter or summer time 
even if both clients are in the same time zone.
Right now i see no acceptable workaround for this problem.

> Also note of e_cal_backend_set_default_zone and
> e_cal_backend_internal_get_default_timezone; I would extend usage of the
> default timezone to convert UTC times of events to this timezone, if the
> user's timezone is not present. Though it'll be better to do some
> testing whether such extension wouldn't bring more trouble than gain.

I think we could get the same trouble as converting from evolution to kolab. 
If there is a recurring event which is created in kontact i think it would be 
better to let the UTC time unchanged in evolution. Because evolution seems to 
be able to handle the UTC time and the times are the same in both clients 
then.
If the recurring event is first created in evolution this can be different. We 
could preserve the timezone information (although if it is not handled by 
kolab clients like kontact) and restore it when converting back from kolab. 
But if the times of this event are changed in kolab we maybe should discard 
the local timezones.
The best option i think would be to adapt the kolab format to handle local 
timezones. I just wrote a mail to the kolab-format mailing list to ask if 
they have an idea how this problem could be solved.

Thanks & Greetings,

Hendrik


[1] http://kolab.org/doc/kolabformat-2.0rc7-html/x123.html

> 	Bye,
> 	Milan




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]