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

[David Jarvie]

On Wednesday 09 May 2007 16:51:37 Reinhold Kainhofer wrote:
> 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:
> 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).

You could extract RRULE strings from the VTIMEZONE string. Of course, there 
would be the problem of relating them to specific phases unless the whole 
VTIMEZONE string was parsed, which rather defeats the purpose of parsing it 
via ICalTimeZone.

> 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.

Perhaps what is needed is indeed a KCal::TimeZone class. This could take any 
KTimeZone instance (including derived classes such as ICalTimeZone) and 
provide methods to extract Recurrence objects, RRULE strings, etc.

> > >> 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.

Thinking a bit more about it, probably xCalendar could be handled simply by a 
KTimeZoneSource derived class. That would be the only difference from 
iCalendar. ICalTimeZone and ICalTimeZoneData would be used unchanged.

> > > 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)

Again, this might be best handled by a KCal::TimeZone class.

The question which arises from what you say is, should ICalTimeZone be amended 
to allow extraction of particular strings from VTIMEZONE? 

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm
_______________________________________________
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/