[Kde-pim] Problem with icaltimezones being only a wrapper for libical

[Reinhold Kainhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Mittwoch, 9. Mai 2007 schrieb David Jarvie:
> On Wednesday 9 May 2007 13:43, Reinhold Kainhofer wrote:
> > Am Mittwoch, 9. Mai 2007 schrieb David Jarvie:
> >> You CAN fetch complete information for a time zone from the ICalTimeZone
> >> class. See also the KTimeZone documentation.
> >
> > Okay, so how do I get the recurrence rule? (I need the iCal string, but
> > if I get all the bits and pieces, I can construct that easily).
>
> ICalTimeZone::vtimezone() returns the VTIMEZONE component as a string, and
> ICalTimeZone::icalTimezone() returns the icaltimezone structure for the
> time zone.

Both of which is not what I need. If the iCalendar representation is
     BEGIN:VTIMEZONE
     TZID:US-Eastern
     LAST-MODIFIED:19870101T000000Z
     TZURL:http://zones.stds_r_us.net/tz/US-Eastern
     BEGIN:STANDARD
     DTSTART:19671029T020000
     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
     TZOFFSETFROM:-0400
     TZOFFSETTO:-0500
     TZNAME:EST
     END:STANDARD
     BEGIN:DAYLIGHT
     DTSTART:19870405T020000
     RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
     TZOFFSETFROM:-0500
     TZOFFSETTO:-0400
     TZNAME:EDT
     END:DAYLIGHT
     END:VTIMEZONE
then I need only the strings "FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10" 
and "FREQ=YEARLY;BYDAY=1SU;BYMONTH=4" (i.e. the RRULE property values), or 
maybe even the separate parts of the rule (rdfCalendar splits the RRULE up 
into separate XML tags).

And working with any libical object should be forbidden in libkcal altogether. 
Given that libical is practically not maintained any more, it's very 
dangerous to rely even more on it..

> >> ICalTimeZone is inherited from KTimeZone which provides a generic
> >> interface to time zone data. To access/write xCalendar time zone data, a
> >> new class also inherited from KTimeZone would be needed, tailored to
> >> that
> >> particular data source.
> >
> > Hmm, all I need is the exact information as it would be written (and as
> > it is read!) to the iCalendar file. xCalendar is basically a ~1:1
> > translation of iCal into XML...
>
> You might still need xCalendar time zone classes - they wouldn't
> necessarily be difficult to implement, since they would use ICalTimeZone*
> and just do conversions between iCalendar and xCalendar.

Yeah, that's what I don't understand here. Why should the object in memory be 
tailored for one specific format? We don't have an iCalendarEvent and a 
vCalendarEvent and a OGoEvent, but only one Event class. The format plugins 
then can simply assign the correct values on loading and extract the stuff 
they need when saving from the Event class. 
The same holds true for recurrences (well, internally its structure has close 
ties to iCalendar RRULES, but it models vCalendar RRULEs just as well), which 
is the same class for iCalendar-style and vCalendar-style recurrences.

I think that's also the way it should work for the time zone representations. 
An external formatter class can interpret each import format (or save to each 
export format) and assign the appropriate values to one (and only one) time 
zone class, independent of the format used for storage.

> > Something else (just from looking at the API docs): To get all
> > transitions for a given phase, is there any convenience method, or does
> > one have to
>
> loop
>
> > manually over all phases and check the corresponding phases for each
> > transition?
>
> You have to do it manually. Is that something which KTimeZone should
> really offer as a method?

I don't know. I need it to write out all RDATEs for a <iCal:Standard> or 
<iCal:Daylight> child of the <iCal:vTimeZone>. (i.e. in iCalendar terms for 
each BEGIN:STANDARD and BEGIN:DAYLIGHT)

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGQe4KTqjEwhXvPN0RAkShAJ9bWn765XM5wN+yUjhu8fwdNGyXqgCePFbx
/+Emucww63jNBfKxv/1+J5E=
=bOq6
-----END PGP SIGNATURE-----
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/