X-WR-TIMEZONE causes EXDATE of series to be ignored

[dominikschreiber]

Issue Description

I'm experiencing deleted series entries of a google calendar being shown in the $ical->eventsFromRange result. In my attempt to find out why this happens, I observed that X-WR-TIMEZONE:Europe/Berlin seems to cause the EXDATE to be ignored. If you remove this line, the EXDATE has effect.

See a minimal example below.

Sadly I'm too bad of a php developer to fix this with a pull request, but I hope you can work with the information I have here.

Minimal Example

# file: basic.ics
BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-TIMEZONE:Europe/Berlin
BEGIN:VEVENT
DTSTART:20161205T140000
DTEND:20161205T160000
RRULE:FREQ=MONTHLY;BYDAY=1MO
EXDATE:20170102T140000
DTSTAMP:20161206T211738Z
SEQUENCE:0
STATUS:CONFIRMED
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

<?php // file: index.php
date_default_timezone_set('europe/berlin');
$ical = new ICal(explode("\r\n", file_get_contents("basic.ics")));
?>
<ul><?php foreach ($ical->eventsFromRange("2017-01-01", "2017-03-31") as $e) { ?>
  <li><?php echo strftime("%d.%m.%y", $ical->iCalDateToUnixTimestamp($e->dtstart)); } ?>
</ul>

Expected Result

• 06.02.17
• 06.03.17

Actual Result

• 02.01.17
• 06.02.17
• 06.03.17

[u01jmg3]

• Just ran the parser against your snippet and it produced what was expected.

• As per the issue guidelines, have you checked you are using the latest version (dev-master)?

[dominikschreiber]

I just required dev-master again, and the following php code produces the very error I reported:

<?php
require_once "./vendor/autoload.php";

use ICal\ICal;

date_default_timezone_set('europe/berlin');
$ical = new ICal([
	"BEGIN:VCALENDAR",
	"VERSION:2.0",
	"CALSCALE:GREGORIAN",
	"METHOD:PUBLISH",
	"X-WR-TIMEZONE:Europe/Berlin",
	"BEGIN:VEVENT",
	"DTSTART:20161205T140000",
	"DTEND:20161205T160000",
	"RRULE:FREQ=MONTHLY;BYDAY=1MO",
	"EXDATE:20170102T140000",
	"DTSTAMP:20161206T211738Z",
	"SEQUENCE:0",
	"STATUS:CONFIRMED",
	"TRANSP:OPAQUE",
	"END:VEVENT",
	"END:VCALENDAR"
]);
?>
<ul><?php foreach ($ical->eventsFromRange("2017-01-01", "2017-03-31") as $e) { ?>
  <li><?php echo strftime("%d.%m.%y", $ical->iCalDateToUnixTimestamp($e->dtstart)); } ?>
</ul>

[u01jmg3]

@dominikschreiber: the latest dev-master should correct your issue. Can you try once last time, please?

[dominikschreiber]

Hey, sorry for me appearing offensive last time. I didn't mean it, you're doing a great work on your free time, and I really want to thank you for that.

Commit f9f5866 fixes this issue. For some reason, I have a huge performance drop from commit dde72dc (~3s to load https://calendar.google.com/calendar/ical/efg.ludwigshafen%40gmail.com/public/basic.ics, parse it, and render all events in a month in a table) over f9f5866 (~15s) to 4de3963 (~45s). I'm ok with that (use it for a script running once every 2 months), but this feels quite alarming...

[u01jmg3]

@dominikschreiber - glad to hear I have fixed the problem you reported in this issue. I shall look into the performance drop you mentioned (#99) and see what could be the cause.

[u01jmg3]

@dominikschreiber - I have analysed all 20 commits since the release of v2.0.1 and found there to be 2 bottlenecks.

1. One surrounded using iCalDateToUnixTimestamp() in f9f5866 which always used a regex to parse the time zone
   • This has been changed in 9d44e5c to check that a time zone exists before trying to parse it
2. The second issue related to 48d285b and populating the DTSTART_array
   • The code was inefficient and has been improved in 9d44e5c

---

• Finally it is worth noting that in b7b3ee6 the recurrence rule logic to handle EXDATE data when a count is imposed has been corrected so that EXDATEs don't count towards an imposed count.
  • This means you may have more event data resulting in increased processing times.