Data::ICal::DateTime 0.82 implements the fix discussed below.
0.82 - Mon 21 Aug 2017
* Set recurrence timezone to the same as the 'start' attribute (fix
github issue #2)
2017-08-18 21:10 GMT+02:00 Flavio S. Glock <fgl...@gmail.com>:
> This patch fixes the problem - but as I explained in the previous mail,
> I'm not sure if it is the right thing to do (the alternative is that
> DateTime::Event::ICal didn't ignore the time_zone in dtstart).
>
> diff --git a/lib/Data/ICal/DateTime.pm b/lib/Data/ICal/DateTime.pm
> index ecf9e2f..ab49e78 100644
> --- a/lib/Data/ICal/DateTime.pm
> +++ b/lib/Data/ICal/DateTime.pm
> @@ -499,6 +499,7 @@ sub _rule_set {
> for (@{ $self->property($name) }) {
> my $recur = DateTime::Format::ICal->parse_recurrence(recurrence
> => $_->value, dtstart => $start);
> # $recur->set_time_zone($_->parameters->{TZID}) if
> $_->parameters->{TZID};
> + $recur->set_time_zone($start->time_zone) if
> !$start->time_zone->is_floating;
> $set = $set->union($recur);
> }
> # $set->set_time_zone($tz);
>
>
> 2017-08-18 19:27 GMT+02:00 Flavio S. Glock <fgl...@gmail.com>:
>
>> (forwarding to DateTime list because this looks interesting)
>>
>> I've created this test - https://gist.github.com/fglock
>> /cf1117ad000b41d9e5dbee6fa8b78993
>>
>> this fails (set time zone implicitly through dtstart):
>>
>> $a = DateTime::Event::ICal->recur(
>> dtstart => $dt19970902T090000_tz ,
>> freq => 'daily',
>> count => 10 )
>> ->intersection( $period_1995_1999 );
>>
>> this other test works (time zone is set explicitly for the whole
>> recurrence):
>>
>> $a = DateTime::Event::ICal->recur(
>> dtstart => $dt19970902T090000_tz ,
>> freq => 'daily',
>> count => 10 )
>> ->set_time_zone( "America/New_York" )
>> ->intersection( $period_1995_1999 );
>>
>> I believe this is the correct behaviour (though it should warn!), because
>> http://www.ietf.org/rfc/rfc2445.txt
>> says:
>>
>> <quote>
>>
>> Dawson & Stenerson Standards Track [Page 117]
>>
>> RFC 2445 iCalendar November 1998
>>
>>
>> The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION"
>> property pair, specified within the iCalendar object defines the
>> first instance of the recurrence. When used with a recurrence rule,
>> the "DTSTART" and "DTEND" properties MUST be specified in local time
>> and the appropriate set of "VTIMEZONE" calendar components MUST be
>> included. For detail on the usage of the "VTIMEZONE" calendar
>> component, see the "VTIMEZONE" calendar component definition.</quote>
>>
>> I *think* DateTime::Event::ICal is doing the right thing, but the module
>> documentation is not clear:
>>
>> <quote>
>>
>> This method takes parameters which correspond to the rule parts
>> specified in section 4.3.10 of RFC 2445. Rather than rewrite that RFC
>> here, you are encouraged to read that first if you want to understand
>> what all these parameters represent.
>>
>> </quote>
>>
>> It *could* as well also use the time_zone from "dtstart".
>>
>> Simon: do you think this explains the problem, and can this can be fixed in
>> your module maybe?
>>
>> Flávio S. Glock
>>
>>
>>
>> 2017-08-18 18:28 GMT+02:00 Flavio S. Glock <fgl...@gmail.com>:
>>
>>> just to confirm, I did a fresh install and I get:
>>>
>>> t/01.parse_recurring.t ...... 1/18
>>> # Failed test at t/01.parse_recurring.t line 25.
>>> # got: 'floating'
>>> # expected: 'Europe/London'
>>>
>>> I'm investigating a bit
>>>
>>> Flávio
>>>
>>>
>>> 2017-08-18 17:33 GMT+02:00 Th.J. van Hoesel <slrn406268...@gmail.com>:
>>> > just fiddling along, it works if I first install
>>> FGLOCK/DateTime-Event-Recurrence-0.16
>>> >
>>> >> On 18 Aug 2017, at 15:34, Th.J. van Hoesel <th.j.v.hoe...@me.com>
>>> wrote:
>>> >>
>>> >> Hi Flávio, Hello Simon,
>>> >>
>>> >> i've some issues with installing Data::Ical::DateTime and I can not
>>> exactly say who is in the right or who is in the wrong, that would require
>>> more investigation.
>>> >>
>>> >> Data::Ical::DateTime is depending on DateTime::Event::Recurrence,
>>> with is dependent on DateTime::Set. When that was changed back in november
>>> 2015, that is when Data::ICal::DateTime started failing on CPAN testers.
>>> >>
>>> >> Maybe one does a wrong call and should actually had expected to get
>>> "floating" timezones, maybe one does expected that his timezone from the
>>> .ics test file would be honoured.
>>> >>
>>> >> Could you please be so kind and have a look, you probably do
>>> understand the problem-space much better than I do. Would I have
>>> understood, I probably would had sent a bug fix
>>> >>
>>> >> Theo
>>> >>
>>> >> PS. It is part of the "Act-out-of-the-Box" install script, and it
>>> just looks ugly to do a force install, but it will do the job for now
>>> >
>>>
>>
>>
>>
>
