Parser Doesnt Handle Language Tag

[bateller]

For text tags with the Language tag added, the parser doesn't know how to behave.

Example: SUMMARY;LANGUAGE=en-us:Office Workgroup Focus Group Normally this would be: SUMMARY:Office Workgroup Focus Group

With added language tag, the SUMMARY tag, or whatever... isn't parsed properly. (Outputs nothing)

Should return an array of: ('SUMMARY' => 'Office Workgroup Focus Group')

Instead returns an array of: ('SUMMARY' => '')

This issue might also affect timezone settings: eg. DTEND;TZID="Eastern Standard Time":20130502T180000 DTSTART;TZID="Eastern Standard Time":20130502T130000 etc.

[johngrogg]

I'll see if I can find time this week to take a look at why that's happening (likely from assumptions by the original designer on what can be after the SUMMARY and DT tags).

If you can, could you attach an ics file or link that exhibit the behavior?

[bateller]

Yeah the main project seemed stagnant so I was hoping to maybe further develop here. I'm trying to sterilize the ICS file before passing it to the parser so it'll handle it correctly. I attached a ICS file that includes a recurring event "High Energy Aquatics" which should run at 5pm - 6pm but runs 12am-1am when running through the iCal parser.

These events were straight from Google Calendar's ICS export. So I'm assuming the format should be standard.

*I couldn't upload the file, so I posted as a separate comment below.

[bateller]

Text of ICS file uploaded:

BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH X-WR-CALNAME:Event Calendar X-WR-TIMEZONE:America/New_York X-WR-CALDESC: BEGIN:VTIMEZONE TZID:America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID=America/New_York:20130613T100000 DTEND;TZID=America/New_York:20130613T110000 RRULE:FREQ=WEEKLY;UNTIL=20130829T140000Z;BYDAY=TH EXDATE;TZID=America/New_York:20130704T100000 DTSTAMP:20130610T131342Z UID:mnd3osv524guvarlq9t9gefuc0@google.com CREATED:20130517T180924Z DESCRIPTION: LAST-MODIFIED:20130517T180924Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:High Energy Aquatics TRANSP:OPAQUE END:VEVENT BEGIN:VEVENT DTSTART;TZID=America/New_York:20130610T170000 DTEND;TZID=America/New_York:20130610T180000 RRULE:FREQ=WEEKLY;UNTIL=20130827T210000Z;BYDAY=MO,TU DTSTAMP:20130610T131342Z UID:aksa2evf42ivfk4eheh00co77c@google.com CREATED:20130517T180654Z DESCRIPTION: LAST-MODIFIED:20130517T180654Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:High Energy Aquatics TRANSP:OPAQUE END:VEVENT BEGIN:VEVENT DTSTART;VALUE=DATE:20130610 DTEND;VALUE=DATE:20130611 RRULE:FREQ=WEEKLY;UNTIL=20130611;BYDAY=MO,TU DTSTAMP:20130610T131342Z UID:737fkc0pjdvn0aihut6d7gg928@google.com CREATED:20130517T175820Z DESCRIPTION: LAST-MODIFIED:20130517T175820Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Pavilion & Beach Bar Closed TRANSP:TRANSPARENT END:VEVENT END:VCALENDAR

[johngrogg]

Yeah the main project seemed stagnant so I was hoping to maybe further develop here. Completely understand, that's why I put this out there!

I'm pretty sure the class was originally built to work with Microsoft Exchange generated ics files (I know that's all I used for testing the recurrence, though I tried to cover all of the spec rules I could find, even ones it appears Exchange never uses), and it's likely Exchange never did what Google is doing in that file.

Hopefully I'll have time this week to figure out a solution. In the mean time, if you figure out a workaround yourself feel free to submit a pull request to a fixed version and I'll merge it into this repo.

[bateller]

Understood. I've been working on it a better part of today actually. Its for a end customer so I need to figure something out either way.

We are importing events into our own system and provide the ability for clients to import external ICS files (in this case someone is using Google). Events import fine unless they are recurring. So that's how I came across your modification.

I'm able to get it all working except for the "times" of the events.

For instance...

If you have a recurring event with DTSTART and DTEND keys like: DTSTART: 20130610T170000 - UNIX-Time: 06-10-2013 5:00 pm DTEND: 20130610T180000 - UNIX-Time: 06-10-2013 6:00 pm

and an RRULE: RRULE:FREQ=WEEKLY;UNTIL=20130827T210000Z;BYDAY=MO,TU

It'll create all the required events correctly, on the correct days. However the times are always 12am and 1am. Notice RRULE from Google ICS doesn't appear to use the INTERVAL key.

I'm guessing I could just take the original value for the original DTSTART and add the time from that to the "child" DTSTART's value?

Sample ICS (with only one recurring event) below:

BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH X-WR-CALNAME:Test X-WR-TIMEZONE:America/New_York X-WR-CALDESC:Brian Test from Signera BEGIN:VTIMEZONE TZID:America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTART:20130610T170000 DTEND:20130610T180000 RRULE:FREQ=WEEKLY;UNTIL=20130827T210000Z;BYDAY=MO,TU DTSTAMP:20130716T184543Z UID:aksa2evf42ivfk4eheh00co77c@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Test;X -NUM-GUESTS=0:mailto:10rjqshs1art9g28eiqj35j81c@group.calendar.google.com CREATED:20130517T180654Z DESCRIPTION: LAST-MODIFIED:20130716T184514Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:High Energy Aquatics TRANSP:OPAQUE END:VEVENT END:VCALENDAR

[johngrogg]

Ok, I've figured out the issue with the times being off. I had a few places in the RRULE handling that wasn't keeping the actual even time in the timestamp (specifically some of the strtotime calls).

Should handle the recurrence you posted now.

If you have an example of the SUMMARY bug, or a fix, please provide and I'll find a fix (or you can submit a PULL request).

[johngrogg]

And I've added in a fix for when the keyword of a property is followed by extra info after a ';' (like the example you gave in your first post regarding SUMMARY;LANGUAGE=en-us:Office Workgroup Focus Group)

I think that covers everything you mentioned.

Let me know if there's anything else you catch!