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



Am Mittwoch, 29. September 2010 13:55:51 schrieb Milan Crha:
> On Mon, 2010-09-27 at 15:54 +0200, Hendrik Helwich wrote:
> > while working on a plugin [1] to connect eds  to a kolab server, i need
> > to convert evolution contacts, events, tasks and notes to a kolab email
> > (and back).
> > Right now the idea is to use the class EContact for evolution contacts
> > and ECalComponent for evolution events, tasks and notes.
> > I now noticed, that an event in an evolution iCalendar file contains a
> > VTIMEZONE and a VEVENT block, and the VEVENT block depends to a timezone
> > which is defined in the VTIMEZONE block.
> > The ECalComponent seems to hold only one block of an iCalendar object and
> > it is therefore not possible to get all the informations of an evolution
> > event from one ECalComponent.
>
> 	Hi,
> I think it was mentioned earlier, the ECalComponent is a wrapper for the
> icalcomponent. Evolution's UI is using ECalComponent, but, say as
> CalDAV, you can operate with icalcomponent internally, when there is a
> need for a VCALENDAR component used in the kolab email.
>
> With respect of VTIMEZONE, the ECalComponent has times/dates stored as
> ECalComponentDateTime structure, which has 'tzid' member (it's a const
> gchar *), and when the UI or a util function needs the VTIMEZONE, then
> it asks ECal through e_cal_get_timezone, which calls, through DBus these
> days, ECalBackend's e_cal_backend_get_timezone function.
>
> Note also that there is a default timezone for the ECalBackend, and that
> timezones can be also added to the backend from outside, not only from
> the server. It's used when copying events between backends, for example.
>
> Most ECalBackend-s are using ECalBackendStore, which has a facility to
> store both components and timezones.
> 	Hope that helps,
> 	Milan


Hi,

thanks for the information :-)
So one option for us is to operate on the icalcomponent instead of 
ECalComponent.
In our project we do not need any time zone information which is attached to 
time data. It would be sufficient if all time data is stored in UTC format. 
Then we could stay with the ECalComponent class.
Is there an easy way in evolution to strip timezone information from an 
ECalComponent by converting local time data to UTC time data?

Greetings,
Hendrik



-- 
tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH
Geschäftsführer: Boris Esser, Elmar Geese
HRB AG Bonn 5168 - USt-ID (VAT): DE122264941

Heilsbachstraße 24,  53123 Bonn,   Telefon: +49 228 52675-0
Thiemannstraße 36 a, 12059 Berlin, Telefon: +49 30 5682943-30
Internet: http://www.tarent.de/  • Telefax: +49 228 52675-25


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