[Kde-pim] Libical versus system time zones

[David Jarvie]

On: Friday 24 November 2006 01:12, David Jarvie wrote:
> 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.

It must have been too late at night when I wrote this - of course, the reason that the system time zones are output as RDATE values rather than RRULE values is that the tzfile format used to define system time zones, holds a sequence of time transitions rather than storing rules. Another approach to generating the VTIMEZONE component would be to attempt to recognise the date sequence as a rule. For future dates at least, this seems likely to succeed since most future dates are likely to have been generated by a rule in the first place. Combining this approach with the removal of earlier than needed dates might well solve the issue.

--
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html

_______________________________________________
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/