[Kde-pim] Libical versus system time zones

[David Jarvie]

On Thursday 16 November 2006 23:56, David Jarvie wrote:
> On Thursday 16 November 2006 22:29, Reinhold Kainhofer wrote:
> > Am Don Nov 16 2006 schrieb David Jarvie:
> > > I'm going to replace the time zone conversion code in
> > > kresources/lib/webdavhandler.cpp (function zoneAsUtc() etc.) which
> > > currently calls libical functions, with KDateTime based code.
> > > Currently, it uses the built-in libical time zones when converting. Is
> > > there any preference as to whether the system time zones or the libical
> > > time zones should be used when I replace the old code?
> > >
> > > This raises the general question as to whether libkcal should normally
> > > use the built-in libical time zones, or the system ones.
> >
> > If the system time zones can be properly exported to a VTIMEZONE and put
> > into an .ics file, I'd tend to prefer the system time zones. Of course,
> > an ical calendar can (and actually should) provide its own time time zone
> > definitions, which should then be used....
>
> The ICalTimeZone class provides the ability to export system time zones
> into VTIMEZONE components, and this is now used in
> icalformat.cpp/icalformatimpl.cpp. So it's possible to use system time
> zones just as easily as built-in libical time zones.
>
> > As libical is no longer maintained, I suppose sticking with its TZ
> > definitions is not such a good idea in any case.
>
> That's a convincing argument.

Actually, I was mistaken - libkcal as it stands does actually write built-in 
libical time zones rather than system time zones into VTIMEZONE components. 
I've fixed this in my private copy of the library, but the results don't look 
good. Whereas libical time zones normally consist of two simple RRULEs (one 
for summer and one for winter time) applying to recent years, the system time 
zones (on my system at least) use only RDATE values and start from the early 
20th century. As a result, the system time zone in VTIMEZONE format is very 
long - for example, Europe/London is 285 lines long excluding blank lines. By 
contrast, the libical VTIMEZONE is only 17 lines long. I attach both versions 
for those who are interested.

I don't think that we should write such massive VTIMEZONE components as would 
be produced by writing full system time zones. One option to cut down the 
size would be to omit all data which only applies to dates earlier than the 
earliest incidence dates. It would still be uglier than the libical version, 
but assuming an earliest date of 2006, that would cut down the example to a 
mere 79 lines. It would also be possible to remove data applying only after 
the end date of incidences, which would at least some of the time reduce the 
size further.

Comments please.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: systemtz.ics
Type: text/calendar
Size: 9742 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20061124/94d4b199/attachment.ics>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libicaltz.ics
Type: text/calendar
Size: 328 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20061124/94d4b199/attachment-0001.ics>
-------------- next part --------------
_______________________________________________
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/