Bug #47841 for iCal-Parser: iCal::Parser bugs: events starting at 0000 on end-date, events spanning month boundary

Mon Jul 13 15:20:52 2009 jeff.brandenburg [...] duke.edu - Ticket created

CC:	sally.gewalt [...] duke.edu
Subject:	iCal::Parser bugs: events starting at 0000 on end-date, events spanning month boundary
Date:	Mon, 13 Jul 2009 15:20:15 -0400
To:	bug-ical-parser [...] rt.cpan.org
From:	Jeffrey L Brandenburg <jeff.brandenburg [...] duke.edu>

Hello -- I'm a Perl neophyte working with iCal::Parser as part of a resource-usage-reporting application. I've found what appear to be two bugs. Events that start at 0000 on the end-date I pass as an argument to new() get included improperly. I think that this line in VEVENT: return if $start > $self->{span}->end; should instead be return if $start >= $self->{span}->end; ...but I'm not sure whether this is comparing the event's start to the interval's end, or vice-versa (in which case my "fix" is wrong). Events which span the end of a month don't get broken down into individual days as they should. The problem appears to be in this line: if (!$e{allday} && $end->day > $start->day) { It looks like this should be something like if (!$e{allday} && ($end->day > $start->day) || ($end->month > $start->month) || ($end->year > $start->year)) { I'm going to try to patch this in my local installation, but as I said, I'm a Perl neophyte, and I'm not especially confident. If anybody is still interested in maintaining this code for iCal victims like myself, I'm very grateful. Thanks! -- -jeffB (Jeff Brandenburg, Duke Center for In Vivo Microscopy)

Fri Jul 17 12:59:18 2009 rick [...] rickster.com - Correspondence added

Subject:	Re: [rt.cpan.org #47841] iCal::Parser bugs: events starting at 0000 on end-date, events spanning month boundary
Date:	Fri, 17 Jul 2009 16:58:59 +0000
To:	bug-iCal-Parser [...] rt.cpan.org
From:	Rick Frankel <rick [...] rickster.com>

On Mon, 13 Jul 2009 15:20:53 -0400, "Jeffrey L Brandenburg via RT" <bug-iCal-Parser@rt.cpan.org> wrote: Show quoted text

> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=47841 > > > > > Events that start at 0000 on the end-date I pass as an argument to new() > get included improperly. I think that this line in VEVENT: >

This is not a bug. end date is inclusive (as/of 23:59) so, something that starts at midnight is within the time period. Show quoted text

> > > Events which span the end of a month don't get broken down into

individual Show quoted text

> days as they should. The problem appears to be in this line: > > if (!$e{allday} && $end->day > $start->day) { > > It looks like this should be something like > > if (!$e{allday} && ($end->day > $start->day) || ($end->month > > $start->month) || ($end->year > $start->year)) { >

This is possible. I will create a test event and try and check/fix this asap. rick

Fri Jul 17 12:59:19 2009 The RT System itself - Status changed from 'new' to 'open'

Fri Jul 17 14:10:51 2009 jeff.brandenburg [...] duke.edu - Correspondence added

CC:	sally.gewalt [...] duke.edu
Subject:	Re: [rt.cpan.org #47841] iCal::Parser bugs: events starting at 0000 on end-date, events spanning month boundary
Date:	Fri, 17 Jul 2009 14:10:20 -0400
To:	bug-iCal-Parser [...] rt.cpan.org
From:	Jeffrey L Brandenburg <jeff.brandenburg [...] duke.edu>

Message body is not shown because sender requested not to inline it.

Hi, Rick -- I tested my fixes locally, and they worked, but they created one other bug which caused events ending on midnight to be split into the original event and a zero-hour event starting and ending on midnight of the following date. I think I've fixed that one, too. I'm attaching my code for your perusal; I'm not sure what the standard procedure is these days for generating diffs, but the changes are quite limited in scope. I did rename my modified module to "FixedParser" so I could switch back and forth between old and new for testing. I don't have a "test suite" as such, but I set up a calendar in iCal, created some events starting, ending, and spanning midnight, both within and across month boundaries. (I haven't tested year boundaries, but it seems pretty straightforward.) I can pass an .ics file along if you'd like. Thanks for taking care of this! -- -jeffB (Jeff Brandenburg, Duke Center for In Vivo Microscopy) "rick@rickster.com via RT" <bug-iCal-Parser@rt.cpan.org> wrote on 07/17/2009 12:59:20 PM: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=47841 > > > > > > On Mon, 13 Jul 2009 15:20:53 -0400, "Jeffrey L Brandenburg via RT" > <bug-iCal-Parser@rt.cpan.org> wrote: >

> > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=47841 > > > > > > > > > Events that start at 0000 on the end-date I pass as an argument to

new() Show quoted text

> > get included improperly. I think that this line in VEVENT: > >

> This is not a bug. end date is inclusive (as/of 23:59) so, something

that Show quoted text

> starts at midnight is within the time period.

> > > > > > Events which span the end of a month don't get broken down into

> individual

> > days as they should. The problem appears to be in this line: > > > > if (!$e{allday} && $end->day > $start->day) { > > > > It looks like this should be something like > > > > if (!$e{allday} && ($end->day > $start->day) || ($end->month > > > $start->month) || ($end->year > $start->year)) { > >

> This is possible. I will create a test event and try and check/fix this > asap. > > rick >

Tue Nov 29 09:26:10 2011 HMBRAND [...] cpan.org - Correspondence added

RT-Send-CC:

sally.gewalt [...] duke.edu, rick [...] rickster.com

Yes, when written correct, this really improves on allday events. You just forgot two parens: if (!$e{allday} && ( # ÷÷÷ RT 47841 ($end->day > $start->day) || ($end->month > $start->month) || ($end->year > $start->year) )) { $self->add_span(\%e); return; }

Tue Jul 08 13:23:14 2014 https://www.google.com/accounts/o8/id?id=AItOawlsFr716ITHX5fFqEoy1RDF6vBODDmICWg - Correspondence added

From:

bruce [...] momjian.us

I can confirm the patch above, with the paren adjustment, fixes my problem of zero-time midnight entries. Is there a reason these old patches are not being integrated into a new release? Does this project need a new maintainer?

Wed Jul 09 10:20:31 2014 https://www.google.com/accounts/o8/id?id=AItOawlsFr716ITHX5fFqEoy1RDF6vBODDmICWg - Correspondence added

From:

bruce [...] momjian.us

Here is the the extracted, corrected patch that, I think, just fixes the date calculations.

Subject:

zero-events.diff

FixedParser fixes a problem with iCal::Parser where events that spanned a month or year boundary -- precisely, events whose start day-of-month was not numerically greater than their end day-of-month -- did not get expanded. It also fixes a problem where events that end at midnight were split, generating a bogus zero-hour event starting and ending at 0000h the next day. FixedParser fixes a problem in the original iCal::Parser where events starting PRECISELY at the end date -- that is, at 0000h on the end date -- were improperly included. *** /usr/local/share/perl/5.10.1/iCal/Parser.pm.orig 2013-06-15 08:42:05.000000000 -0400 --- /usr/local/share/perl/5.10.1/iCal/Parser.pm 2014-07-08 09:55:00.000000000 -0400 *************** *** 106,112 **** $self->add_objects($event,\%e); my $start=$e{DTSTART}; ! return if $start > $self->{span}->end; warn "Event: @e{qw(UID DTSTART SUMMARY)}\n" if $self->{debug}; --- 103,109 ---- $self->add_objects($event,\%e); my $start=$e{DTSTART}; ! return if $start >= $self->{span}->end; warn "Event: @e{qw(UID DTSTART SUMMARY)}\n" if $self->{debug}; *************** *** 137,143 **** # non-rrule event possibly spanning multiple days, # expand into multiple events my $diff=$end-$start; ! if (!$e{allday} && $end->day > $start->day) { $self->add_span(\%e); return; } --- 134,143 ---- # non-rrule event possibly spanning multiple days, # expand into multiple events my $diff=$end-$start; ! if (!$e{allday} && ! ($end->day > $start->day || ! $end->month > $start->month || ! $end->year > $start->year)) { $self->add_span(\%e); return; } *************** *** 342,353 **** $t{DTSTART}=$d->clone; $t{DTEND}=$d->clone->add(days=>1); $t{hours}=_hours($t{DTEND}-$t{DTSTART}); ! push @a,\%t; } } my($start,$end)=($self->{span}->start,$self->{span}->end); map {$self->add_event($_)} grep { ! $_->{DTSTART} >= $start && $_->{DTEND} <= $end } $event,@a,\%last; } 1; --- 343,358 ---- $t{DTSTART}=$d->clone; $t{DTEND}=$d->clone->add(days=>1); $t{hours}=_hours($t{DTEND}-$t{DTSTART}); ! push @a,\%t; } } my($start,$end)=($self->{span}->start,$self->{span}->end); map {$self->add_event($_)} grep { ! # don't add "events" with no hours (i.e. events that ! # start and end at midnight, arising from events ! # that start the day before and end at midnight) ! # $_->{DTSTART} >= $start && $_->{DTEND} <= $end ! $_->{DTSTART} >= $start && $_->{DTEND} <= $end && $_->{hours} > 0.0 } $event,@a,\%last; } 1;

Sun Mar 05 21:14:46 2017 https://me.yahoo.com/lkjasdifjoijwe2323#348d4 - Correspondence added

From:

bruce [...] momjian.us

On Wed Jul 09 10:20:31 2014, https://www.google.com/accounts/o8/id?id=AItOawlsFr716ITHX5fFqEoy1RDF6vBODDmICWg wrote: Show quoted text

> Here is the the extracted, corrected patch that, I think, just fixes > the date calculations.

This appears to be fixed in version 1.21. Cedric, thank you for reactivating the development of this module.