TypeError: curr.start.toISOString is not a function

KirAsh4

Just a guess, since I don’t know what calendar you’re using nor what the specific entry might be that’s blowing up, but the lines above that are relevant here:

        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]);
            }
        }

For some reason, the comps variable is failing to get set properly, which then causes the Date() object to fail and things just cascade from there. So you’d have to figure out why it’s failing, or what’s being set in it. What you could do is, in node-ical.js, after line 33, insert the following:

console.dir(comps);

Then run your debug.js file again and see what you get.

Bangee

so i think you are right:

pi@raspberrypi:~/MagicMirror/modules/default/calendar $ node debug.js
Create fetcher ...
Create fetcher done!
undefined
undefined
undefined
/home/pi/MagicMirror/modules/default/calendar/vendor/ical.js/node-ical.js:39
      rule += ';DTSTART=' + curr.start.toISOString().replace(/[-:]/g, '');
                                       ^

TypeError: curr.start.toISOString is not a function
    at Object.ical.objectHandlers.END (/home/pi/MagicMirror/modules/default/calendar/vendor/ical.js/node-ical.js:39:40)
    at Object.handleObject (/home/pi/MagicMirror/modules/default/calendar/vendor/ical.js/ical.js:257:41)
    at Object.parseICS (/home/pi/MagicMirror/modules/default/calendar/vendor/ical.js/ical.js:298:20)
    at Request._callback (/home/pi/MagicMirror/modules/default/calendar/vendor/ical.js/node-ical.js:11:24)
    at Request.self.callback (/home/pi/MagicMirror/node_modules/request/request.js:200:22)
    at emitTwo (events.js:100:13)
    at Request.emit (events.js:185:7)
    at Request.<anonymous> (/home/pi/MagicMirror/node_modules/request/request.js:1067:10)
    at emitOne (events.js:95:20)
    at Request.emit (events.js:182:7)

I’m using office365 calendar, but most of the time, my calendar is running …

So whats next? :-)

KirAsh4

Right, that was simply checking what’s in 'comps', however it appears the variable itself isn’t being set from the line above it. That is assuming you put the 'console.dir()' line in the right spot. :)

So you can literally start sprinkling console calls to try and figure out where and why it’s failing:

console.log("curr contains:");
console.dir(curr);
console.log("curr.start is set to:");
console.log(curr.start);
if (curr.start.length === 8) {
    var comps = /^(\d{4})(\d{2})(\d{2})$/.exec(curr.start);
    console.log("comps array contains:");
    console.dir(comps);
    if (comps) {
        curr.start = new Date (comps[1], comps[2] - 1, comps[3]);
    }
}

Bangee

ok, so here it is:

Create fetcher ...
Create fetcher done!
curr contains:
{ type: 'STANDARD',
  params: [],
  start: { Mon, 01 Jan 1601 02:00:00 GMT tz: undefined },
  tzoffsetfrom: '+0200',
  tzoffsetto: '+0100',
  rrule: 'RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10' }
curr.start is set to:
{ Mon, 01 Jan 1601 02:00:00 GMT tz: undefined }
curr contains:
{ type: 'DAYLIGHT',
  params: [],
  start: { Mon, 01 Jan 1601 01:00:00 GMT tz: undefined },
  tzoffsetfrom: '+0100',
  tzoffsetto: '+0200',
  rrule: 'RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3' }
curr.start is set to:
{ Mon, 01 Jan 1601 01:00:00 GMT tz: undefined }
curr contains:
{ type: 'VEVENT',
  params: [],
  rrule: 'RRULE:FREQ=WEEKLY;UNTIL=20161004T183000Z;INTERVAL=1;BYDAY=TU;WKST=SU',
  uid: '040000008200E00074C5B7101A82E008000000009B3BEC42F394D10100000000000000001000000074F8AEF399AAD4438C6FBCBC8E500415',
  summary: 'Sommertraining',
  start: '00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna":20160524T203000',
  end: '00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna":20160524T220000',
  class: 'PUBLIC',
  priority: '5',
  dtstamp: '20160621T203603Z',
  transparency: 'OPAQUE',
  status: 'CONFIRMED',
  sequence: '0',
  location: 'Tco',
  'MICROSOFT-CDO-APPT-SEQUENCE': '0',
  'MICROSOFT-CDO-BUSYSTATUS': 'BUSY',
  'MICROSOFT-CDO-INTENDEDSTATUS': 'BUSY',
  'MICROSOFT-CDO-ALLDAYEVENT': 'FALSE',
  'MICROSOFT-CDO-IMPORTANCE': '1',
  'MICROSOFT-CDO-INSTTYPE': '1',
  'MICROSOFT-DISALLOW-COUNTER': 'FALSE' }
curr.start is set to:
00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna":20160524T203000
/home/pi/MagicMirror/modules/default/calendar/vendor/ical.js/node-ical.js:45
      rule += ';DTSTART=' + curr.start.toISOString().replace(/[-:]/g, '');

KirAsh4

There’s that failure … Notice the contents of curr.start in each iteration:

curr.start is set to:
{ Mon, 01 Jan 1601 02:00:00 GMT tz: undefined }

curr.start is set to:
{ Mon, 01 Jan 1601 01:00:00 GMT tz: undefined }

curr.start is set to:
00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna":20160524T203000

That’s where it fails. It processes the previous two just fine, then encounters an invalid time stamp. This is something within the Offce386 calendar. What is that event?

Bangee

its a weekly event.

I’ll Try to delete this event and reload, but thats no the solution… :-(

KirAsh4

It doesn’t appear that the event information is valid to begin with, at least not the way that Office386 is serving the information. It doesn’t make sense to me. It should be an array, not a string. So the next question is, is the data you are receiving valid? And if so, where is that getting mangled that 'curr' ends up with an invalid array.

Unfortunately I don’t have/use Office386’s calendar, so I’m not going to be able to debug this unless you want to share your calendar link with me. or, recreate a blank one with similar events and share that.

KirAsh4

Ok, preliminary digging done. It appears the pattern matching isn’t working correctly for the times that Office386 puts on its calendar, I mean, really 1601 for a year? I don’t think so.

Anyway, I’m going to tag @MichMich on this since he wrote the default calendar and I believe the node-ical stuff as well. I have the output of the ICS, so if you had shared it to get me the link, you can unshare it. I can work with the saved output.

Bangee

ok, sounds not that good as expected. Whats next?

KirAsh4

Basically one of us has to find the time to investigate. The way Office386 creates its dates is really odd. Leave it to Microsoft to break things … as always.