libical: revert r1130 (VTIMEZONE transitions)

[Allen Winter]

On Monday, June 08, 2015 12:29:41 PM Allen Winter wrote:
> 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.
> 

Fixed.
By default nothing has changed, but now you have a buildtime and a runtime ability
to switch the behavior from exact to inter-operable VTIMEZONEs.

First the buildtime switch.  if you want to build libical to use inter-operable VTIMEZONEs
without changing your code, then pass the option -DUSE_INTEROPERABLE_VTIMEZONES=true to cmake.

If you are are forced to use a libical that was built without inter-operable VTIMEZONEs as the default,
then you'll need to call icaltzutil_set_exact_vtimezones_support(1) from your application at runtime.

You can also query the VTIMEZONE "mode" by calling the icaltzutil_get_exact_vtimezones_support() function.

I hope this covers every scenario and now consider this issue closed (well, except for possible silly coding errors I may have made)

-Allen