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

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

> Can one store extra entries (like comments or general X-props) into the
> time zone?

No, not as it is currently written. But support for X-props probably
should be added to comply with RFC2445 if the time zone is written out
again.

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

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

> Furthermore: What is the equivalent of iCal's TZOFFSETFROM in the
> KTimeZoneData class?

You have to find the previous phase or transition, and use its UTC offset.
Bear in mind that in VTIMEZONE, a phase is defined in terms of both the
UTC offset before and after the phase start, whereas a KTimeZone phase is
defined only in terms of the UTC offset after the phase start. So phases
which are distinct in VTIMEZONE are not necessarily distinct in KTimeZone
if their before offsets are different.

In general, if there are any methods which might be generally useful, we
should consider adding them to KTimeZone while we're still in the soft API
freeze. (Or is the addition of new methods allowed - I'm not sure whether
the freeze is about source or binary compatibility?)

-- 
David Jarvie.
KAlarm author & 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/