The changes in https://www.drupal.org/node/2710961 seem to have broken multi-instance EXDATE in the way Google Calendar exports it. All instances get concatenated to one line without any delimiters, and neither Date iCal nor Date Repeat can parse the date properly. The end result is that only one (the first?) exception actually gets synced to Date Repeat.

Sample event where this happens:

BEGIN:VEVENT
DTSTART;VALUE=DATE:20160427
DTEND;VALUE=DATE:20160428
RRULE:FREQ=WEEKLY;UNTIL=20160622;BYDAY=WE
EXDATE;VALUE=DATE:20160622
EXDATE;VALUE=DATE:20160504
DTSTAMP:20160630T110439Z
UID:b62m029qpsapu14vibtinbbd0o@google.com
CREATED:20160426T184052Z
DESCRIPTION:
LAST-MODIFIED:20160427T204255Z
LOCATION:
SEQUENCE:2
STATUS:CONFIRMED
SUMMARY:Onsdagsregatta 18:25
TRANSP:TRANSPARENT
END:VEVENT

I don't fully understand what's going on here, but a decent method of solving this for me seems to be doing a preg_match() test and not stripping whitespace if we detect more than one EXDATE in the output of $vcalendar_component->createExdate(). Because iCalcreator IS parsing the EXDATE right, and then we're messing it up by erroneously stripping whitespace.

I'll try to test this with the event included in the related issue to ensure it doesn't break that. Expect a patch :)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

wizonesolutions created an issue. See original summary.

wizonesolutions’s picture

I'm looking at this more closely. date_ical_parse_exceptions() only parses comma-separated EXDATEs properly, and Date Repeat does not seem to support multiple occurrences either. That means that we should actually be ensuring we parse EXDATEs into comma-separated lists. I'm going to see if iCalcreator has any settings that will ensure this. If not, I'll handle in ParserVcalendar.

wizonesolutions’s picture

Nah, iCalcreator actually recommends the multi-line format. And actually, Date Repeat does support it when rendering the nodes e.g. on a calendar. However, this is not apparent in its edit form because the edit form only uses the last EXDATE it receives — instead of adding to its array, it always sets it from scratch. I'm split on what's best to do here, but I think I'm going to go for the approach where we massage the data in the parser. That seems better than waiting for the Date maintainers to deal with that patch. Even though Date Repeat ought to be consistent.

wizonesolutions’s picture

Status: Active » Needs review
FileSize
1.86 KB

That approach worked for me, and I think I have done it in a globally-compatible way. There might be edge cases I don't know about, but this patch works for me, and Date Repeat likes it both on the calendar and on the edit form.

attisan’s picture

:thumbs-up: ... works like a charm (in my case importing from owncloud).

greets

coredumperror’s picture

Status: Needs review » Fixed

I've pushed this patch up to git. It'll appear in the dev build momentarily.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.