#26 More lenient parsing of duration strings

closed
nobody
None
5
2011-08-23
2011-08-16
Kent
No

iCal generates duration strings that don't conform exactly to the RFC. The RFC specifies that only days may be combined with times in a duration string, such as P10DT16H. iCal generates duration strings using weeks, so the equivalent duration would be P1W3DT16H (1 week and 3 days = 10 days).

This patch removes the error checking so that these non-conforming durations are parsed without error.

Discussion

  • Allen Winter
    Allen Winter
    2011-08-20

    I tested your patch, and now the regression test fails on the duration of "P2W1DT5H" . it claims this is valid now.

    I think this is what you intended though? because we actually can write such a duration string we should be able to read the same. right? I wonder why we write such durations in the first place.

     
  • Kent
    Kent
    2011-08-22

    Yes, this is the intended change. iCal will create and send ics files with triggers that include weeks and days. Since I use libical on a Mac, I need to be able to parse durations that come out of iCal even if they don't strictly follow the spec.

    The existing implementation probably rejects weeks and days because of grammar specified in section 4.3.6 of RFC 2445. The grammar there says that a duration date may only consist of days plus a time.

     
  • Allen Winter
    Allen Winter
    2011-08-23

    thanks for the patch. committed in r1093
    will be included with the next libical release

     
  • Allen Winter
    Allen Winter
    2011-08-23

    • status: open --> closed