From: Milan Crha <mcrha@re...> - 2013-05-16 11:50:46
testing libical 1.0, I noticed that when saving an event with a
timezone, its whole daylight saving time change history is saved with
the event, which might be fine with respect of correctness, but also
includes useless information, like in my case, where the first timezone
part begins at 1949 and ends at 2037, while I entered the event today,
in 2013, with one instance only. The saved file has 13KB, while the only
relevant information in it is about 1KB, thus the file is 13 times
larger than necessary. I agree with timezone completeness, totally with
recurring events, but it doesn't make much sense to include range of
timezone which is not covered by the event (especially the past times).
I looked briefly into the icaltimezone.h and didn't find anything what
would suggest as being used for this kind of limiting, hence my
I know I can create a copy of the builtin timezone, remove anything I do
not like from its internal component, and save the modified timezone
instead, but I expect there will be more people wanting to do this, thus
it might make sense to have a buildin function for it in libical itself.
From: Milan Crha <mcrha@re...> - 2013-05-16 12:12:17
On Thu, 2013-05-16 at 13:50 +0200, Milan Crha wrote:
> testing libical 1.0, I noticed that when saving an event with a
> timezone, its whole daylight saving time change history is saved with
> the event, which might be fine with respect of correctness, but also
> includes useless information, like in my case, where the first timezone
> part begins at 1949 and ends at 2037, while I entered the event today,
> in 2013, with one instance only.
Hrm, I just realized that it also breaks interoperability (in some
I save an event, through CalDAV, to:
- a Google calendar, it returns event with only timezone for 1970
(while I saved it with whole history);
- a Zimbra server, it returns event with only the last timezone record,
which is for 2037 (remember, my event is for 2013);
- a DAViCal server, it returns event in a complete form, as I wrote it.
While DAViCal does the most correct thing, it's still wrong with respect
of network usage (not caused by DAViCal), because the CalDAV stores
timezones for each single component, thus it means 12KB more data per
each event stored in a calendar being transferred from (or to) the
server. With absolutely no gain. Count with 1000 items in a calendar and
you get 13MB download, instead of 1MB.