indicator crashes on start - unsupported RDATE parm

Bug #1086554 reported by Ian W Scott
58
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Calendar-Indicator
Confirmed
Critical
Lorenzo Carbonell

Bug Description

I'm encountering this error on 12.10 (32-bit). I'm not sure where the America/New York timezone setting is coming from unless somehow it's on one of my calendars. But I'm located in Toronto, which is in the same tz.

Calendar-Indicator version: 0.1.0.0
#####################################################
Refresh Authorization
{'Authorization': '...'}
<Response [200]>
{'Authorization': '...'}
<Response [404]>
{'Authorization': '...'}
<Response [404]>
{'Authorization': '...'}
<Response [404]>
{'Authorization': '...[[I've removed OAuth id's here but they're in the output]]'}
<Response [404]>
{'Authorization': '...'}
<Response [200]>
{'Authorization': '...'}
<Response [200]>
{'Authorization': '...'}
<Response [200]>
{'Authorization': '...'}
<Response [200]>
{'Authorization': '...'}
<Response [200]>
{'Authorization': '...'}
<Response [200]>
{'Authorization': '...'}
<Response [200]>
{'Authorization': '...'}
<Response [200]>
{'Authorization': '...'}
<Response [200]>
{'Authorization': '...'}
<Response [200]>
2010-09-15T23:30:00Z
1 2010-09-15T23:30:00Z
2 2010-09-15 23:30:00+00:00
3 RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20110608T233000Z;BYDAY=WE
DTSTART:20100915T2330-05:00
RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20110608T233000Z;BYDAY=WE
2012-12-05 01:16:25.308253+05:00
2012-06-04T23:00:00Z
1 2012-06-04T23:00:00Z
2 2012-06-04 23:00:00+00:00
DTSTART:20120604T2300-05:00
RRULE:FREQ=DAILY;COUNT=2
2012-12-05 01:16:25.367124+05:00
2010-12-05T15:30:00Z
1 2010-12-05T15:30:00Z
2 2010-12-05 15:30:00+00:00
3 RRULE:FREQ=WEEKLY;UNTIL=20101212T153000Z;BYDAY=SU
DTSTART:20101205T1530-05:00
. . . [[a whole lot more like this]] . . .
DTSTART:20110110T1300-05:00
RRULE:FREQ=WEEKLY;UNTIL=20110416T035959Z
2012-12-05 01:16:25.489222+05:00
2011-01-10T13:00:00-05:00
1 2011-01-10T13:00:00-05:00
2 2011-01-10 13:00:00-05:00
DTSTART:20110110T1300-05:00

EXDATE;TZID="America/New_York";VALUE=DATE-TIME:20110314T170000Z,20110221T180000Z
Traceback (most recent call last):
  File "/usr/bin/calendar-indicator", line 43, in <module>
    ci=CalendarIndicator()
  File "/usr/share/calendar-indicator/calendarindicator.py", line 210, in __init__
    self.update_menu()
  File "/usr/share/calendar-indicator/calendarindicator.py", line 273, in update_menu
    events2 = self.googlecalendar.getNextTenEvents(self.calendar_id)
  File "/usr/share/calendar-indicator/googlecalendarapi.py", line 539, in getNextTenEvents
    sd = event.get_start_date()
  File "/usr/share/calendar-indicator/googlecalendarapi.py", line 213, in get_start_date
    rrule = dateutil.rrule.rrulestr(el)
  File "/usr/lib/python3/dist-packages/dateutil/rrule.py", line 1099, in __call__
    return self._parse_rfc(s, **kwargs)
  File "/usr/lib/python3/dist-packages/dateutil/rrule.py", line 1054, in _parse_rfc
    raise ValueError("unsupported RDATE parm: "+parm)
ValueError: unsupported RDATE parm: TZID="AMERICA/NEW_YORK"

Revision history for this message
Seb Bacon (seb-bacon) wrote :

I can confirm this is also a problem with TZID="EUROPE/LONDON" (Calendar-Indicator version: 0.1.0.0)
)

Revision history for this message
Brandon (bebuell) wrote :

This also is a problem with TZID="AMERICA/LOS_ANGELES" (Calendar-Indicator version 0.1.0.7.precise .2)

Revision history for this message
Étienne (titizebioutifoul) wrote :

Same here with TZID="Europe/Paris" and calendar-indicator v 0.1.0.0

Revision history for this message
Oceanic (unitedoceanic) wrote :

can confirm with TZID="EUROPE/BERLIN"

Changed in calendar-indicator:
assignee: nobody → Lorenzo Carbonell (lorenzo-carbonell)
importance: Undecided → Critical
status: New → Confirmed
Revision history for this message
Roberto Salomon (roberto-salomon) wrote :

can confirm with TZID=AMERICA/SAO_PAULO on Calendar-Indicator version: 0.1.0.8.quantal.1

Revision history for this message
Leon Marincowitz (lionthinker) wrote :

This still happens in Trusty Tahr.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.