vobject
vobject copied to clipboard
sabre-io
Too strict DateTimeParser
We come to subtle exceptions when dealing with a google calendar exported ics file with sabre\vobject-v3.3.5. Here is the error log:
PHP Fatal error: Uncaught exception 'LogicException' with message 'The supplied iCalendar datetime value is incorrect: 20140623T16' in /<fakedpath>/vendor/sabre/vobject/lib/DateTimeParser.php:40
Stack trace:
#0 /<fakedpath>/vendor/sabre/vobject/lib/DateTimeParser.php(188): Sabre\VObject\DateTimeParser::parseDateTime('20140623T16', Object(DateTimeZone))
#1 /<fakedpath>/vendor/sabre/vobject/lib/Property/ICalendar/DateTime.php(172): Sabre\VObject\DateTimeParser::parse('20140623T16', Object(DateTimeZone))
#2 /<fakedpath>/vendor/sabre/vobject/lib/Recur/EventIterator.php(148): Sabre\VObject\Property\ICalendar\DateTime->getDateTimes(Object(DateTimeZone))
#3 /<fakedpath>/vendor/sabre/vobject/lib/Component/VCalendar.php(280): Sabre\VObject\Recur\EventIterator->__construct(Object( in /<fakedpath>/vendor/sabre/vobject/lib/DateTimeParser.php on line 40
It seems that sabre\vobject treates 20140623T16 as an invalid date-time. iCalendar Spec@RFC5545 shows that ISO 8601.2004 is the spec of date-time. However, according to ISO 8601, 20140623T16 is valid. Here is the code throwing the exception:
static public function parseDateTime($dt, DateTimeZone $tz = null) {
// Format is YYYYMMDD + "T" + hhmmss
$result = preg_match('/^([0-9]{4})([0-1][0-9])([0-3][0-9])T([0-2][0-9])([0-5][0-9])([0-5][0-9])([Z]?)$/',$dt,$matches);
if (!$result) {
throw new LogicException('The supplied iCalendar datetime value is incorrect: ' . $dt);
}
It's clear that sabre\vobject supposes the date-time should always include hhmmss. This might be too strict for date-times like 20140623T16.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
I don't think this is correct. The spec also says:
The format is based on the [ISO.8601.2004] complete representation
emphasis on complete.
Furthermore:
date-time = date "T" time ;As specified in the DATE and TIME
;value definitions
which refers to:
time = time-hour time-minute time-second [time-utc]
which clearly only makes [time-utc] optional, and the rest required. I've used the actual ISO documents to correctly parse these values. While the iCalendar spec uses them, it also defines a subset of them.
The format is based on the [ISO.8601.2004] complete representation
You're correct. It's probably Google does not export the calendar properly.
I also met another exception pointing out that date-time missing for EXDATE. The date-time is also required in the spec, and again google calendar does not behave correctly.
It's great that sabre\vobject aligns strictly to the spec, however, it might lead to frequent exceptions because google calendar is so prevalent. Is it possible for vobject to tolerate non-serious spec-violations gently instead of throwing exceptions? For example, by providing options to treat 20140623T16 as 20140623T160000, ingore EXDATE lines without concret date-time.
I came across the same issue when parsing a client's ics file exported from Google Calendar. It seems that some date formats are incorrect as @xueruini mentioned.
I wonder if sabre/vobject could be compatible with the date format like 20140623T16 so that we can handle some ics files that do not conform to the ISO.8601 standards.
The problem is if we start accepting this type of bug (which is really broken!) we allow this bug to continue it's lifetime, and others may start to assume that this is somehow ok.
I think this is one of those cases where a new bug is introduced in google calendar, which hopefully also gets fixed soon.
At the very least start by creating a new bug report at google, and link back here. Based on their response we can think about perhaps adding a workaround, but perhaps they also respond by saying they can fix it soon.
I reported it in the Google Calendar forum. The link is https://productforums.google.com/forum/#!topic/calendar/mEjKpJGfjB8;context-place=forum/calendar
It seems that Google won't fix this problem any time soon. Could you just make the sabre support the ics files having this kind of date formats? Our customer is anxious for a solution. I will appreciate that very much.
I'm gonna wait it out. It's only been a month. If there's no response during the next CalConnect meeting, I will directly tell the google calendar team.
I notice that this issue was added to the 4.1 milestone, which is awesome. May I know the timeframe for this release?
Right now 4.1 was just a placeholder for everything that's not going to be in the next release. It will likely change, but also my earlier statement regarding this issue has not changed. Next calconnect meeting is in January. After that I'll make a final decision.
My trip didn't happen. Perhaps in the meantime we can add a feature to the repair system, as that wouldn't really have bad side effects. In that case you'd need to call:
$vcalendar->validate(\Sabre\VObject\Node::OPTION_REPAIR);
...to fix the value. How does that sound?
That's great! May I know when this can be implemented? I don't mean to push, but I'm getting major pressure from my customers.
Well if you're under high-pressure I would suggest seeing if you can implement it yourself. I can''t make any promises myself as I'm fairly busy with my own customers.
Frankly I'm surprised you didn't just implement a workaround given that you're under major pressure.
It is a little hard for us to understand the code. Anyway, we will try by ourselves first. Thanks for your attention on this issue.
A work around might be find the invalid dates with a regular expression before you parse.
It seems that google has fixed this bug. I guess you don't have to make a patch any more. Thanks for your help.