fixed calendar, issue 1696, ics file start date is not date type

[Hg347]

Fixes issue #1696
Symptom: calendar does not sync. But has not relation to authentication. The start date was simply not a date so toISOString() failed.
Same fix applied to exdates[i]

Tested with this calendar:
personal.zip

On the other hand might be that the code above, L33-38, failed, unfortunately I can't debug yet:

    if (curr.start.length === 8) {
        var comps = /^(\d{4})(\d{2})(\d{2})$/.exec(curr.start);
        if (comps) {
         curr.start = new Date (comps[1], comps[2] - 1, comps[3]);
        }
      }

[MichMich]

Thanks.
Unfortunately the build has failed due to lifting errors of the changelog. Are you able to fix this?

[Hg347]

Sure. I didn't notice, that you even have an integration build set up. That's great.

[MichMich]

Thanks!

[mattdb]

My PR #1701 (that I was writing just as this was merged) also updates node-ical.js, but uses the "official version" which I believe offers equivalent levels of error handling, but also fixes several other calendar-related issues.

I resolved the conflict on my PR by simply using peterbraden's updated version, but want to make sure that I'm not missing anything or stepping on any toes. Thanks!

[Hg347]

My PR #1701 (that I was writing just as this was merged) also updates node-ical.js, but uses the "official version" which I believe offers equivalent levels of error handling, but also fixes several other calendar-related issues.

I resolved the conflict on my PR by simply using peterbraden's updated version, but want to make sure that I'm not missing anything or stepping on any toes. Thanks!

Indeed, looks much better. I just wonder what happened to curr.exdates, isn't that previous logic required anymore?

[mattdb]

My read on why the exdates logic is no longer needed is this (but as with all things, especially date-related things, I heartily endorse a decent probability I'm off-base):

These objectHandler overrides at the end of node-ical.js are cleaning up / smoothing over some rough edges in ical inputs, specifically removing any milliseconds (. followed by 3 digits) added on to dates in DTSTART and EXDATE fields.

(Potential sidebar): Because the DTSTART and EXDATE dates are used as indexes in the resultant parsed ical object, being overly precise isn't particularly helpful and potentially a source of strange bugs. And I am fairly certain there isn't a use case for events repeating more than once a second.

As to why EXDATEs no longer need to be cleaned up: There was a recent-ish change in ical.js that stores EXDATE date keys as just the date part of the event, all hour/minute/second delineations are dropped. This means events that repeat more than once a day can't both have exceptions (and/or exceptions might get applied to the wrong one of the repeating events on that EXDATE??), but I don't think that events repeating more than once a day is at all common, as far as I know (at least for me, neither Fantastical nor Apple's calendar would allow a frequency smaller than daily). So, since all time information is dropped anyways, no need to partially clean it up beforehand.

[Hg347]

@mattdb I just checked the ical project and it looks not that active. There are open pull requests of 2013! I'm not that sure if it's a good idea to rely on the "official repo". The vows unit tests of master don't work either: "callback not fired".