libical: revert r1130 (VTIMEZONE transitions)

[Ken Murchison]

I haven't been paying attention to this thread. What are we calling exact and interoperable?  I have patches to my local copy of vzic that creates more consolidated VTIMEZONEs using RRULEs rather than RDATEs where appropriate. The output of expanding the VTIMEZONE matches what you get from zdump using the same source material (unpatched vzic produces incorrect data on some edge cases)  I'm not opposed to committing my patches but I might have to separate out the timezone distribution service (tzdist) specific bits. 

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

> On Jun 15, 2015, at 5:29 PM, Allen Winter <winter at kde.org> wrote:
> 
>> 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
> 
> 
> 
> _______________________________________________
> libical-devel mailing list
> libical-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libical-devel