libical: revert r1130 (VTIMEZONE transitions)

[Allen Winter]

On Monday, June 08, 2015 05:53:39 PM Patrick Ohly wrote:
> On Sun, 2015-06-07 at 11:11 -0400, Allen Winter wrote:
> > Howdy,
> > 
> > I intend to revert the old commit 1130 from 3 years ago for the upcoming 2.0 release.
> > Commit message:
> > "Fix TZ rules, make the VTIMEZONE specifier an exact mirror of the transitions in the
> > zone files, so it now uses absolute dates rather than trying to calculate a RRULE.
> > Patch frmo jejb, THanks!
> > Fixes bug IDs: 3432224, 3405041, 2096602
> > also the timezone test program passes 100% now."
> > 
> > It caused several problems pointed out by Patrick, see https://sourceforge.net/p/freeassociation/bugs/95/
> 
> I can add that it has also exaggerated performance issues in Radicale
> where that CalDAV server included all defined VTIMEZONEs in each
> individual item (= one VEVENT), regardless of which time zones were used
> in the item.
> 
> > reverting might bring back  https://sourceforge.net/p/freeassociation/bugs/34/ but that bug was from Patrick too
> 
> Re-reading that bug it seems to me that the Evolution fork must have had
> some bug fixes which did not find their way into upstream libical. But
> it's very hard to be sure anymore.
> 
> > If anyone objects to this plan please let me know asap.
> 
> I'm in favor of it.
> 
> But it would be good to hear also from those who originally proposed
> commit 1130. The commit message mentions bug numbers, but I don't know
> in which bug tracker.
The old sourceforge bug tracker, afaict.
https://sourceforge.net/p/freeassociation/bugs/

> 
> Ultimately the key problem remains: some users of libical need exact
> VTIMEZONEs, others need interoperable ones. libical cannot provide both
> at the same time, so someone needs to choose, either at compile time or
> runtime.
> 
I could add a runtime switch between the different behaviors to the API. 
the default would be the current behavior.
that seems the most useful solution to me, but i'm happy to hear other opinions.