Closed
Bug 317307
Opened 18 years ago
Closed 18 years ago
Errors when subscribing to calendar
Categories
(Calendar :: General, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: pete, Assigned: mostafah)
References
()
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 In versions of Sunbird prior to 0.3a1 it was possible to subscribe to calendars from Upcoming.org. With version 0.3a1 it is not. I was able to subscribe to the calendar if I did a global find/replace in it swapping 'TZID=US-Pacific' with 'VALUE=DATE' I do not know if Upcoming is doing the wrong thing, or Sunbird is. Reproducible: Always Steps to Reproduce: 1. Subscribe to any calendar from Upcoming.org (Try this one: http://upcoming.org/calendar/metro/793 ) Actual Results: Error number: 0x80004005 Description: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [calIIcalComponent.startTime]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///Applications/Sunbird.app/Contents/MacOS/components/calItemBase.js :: anonymous :: line 449" data: no] Expected Results: Subscribed to the calendar without any errors. Bug did not seem to happen in versions of Sunbird prior to 0.3a1
Comment 1•18 years ago
|
||
The calendar file referenced here seems to be invalid. It declares a VTIMEZONE with TZID:America/Portland but then tries to use DTSTART;TZID=US-Pacific:20051201 RFC2445 specifies that if a TZID is to be used, it must be defined previously in a VTIMEZONE. Here, since the timezone used (US-Pacific) is never defined, we fail because of the undefined timezone. If I replace all instances of 'US-Pacific' with 'America/Portland', or vice versa, I can use the calendar without a problem.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•18 years ago
|
||
Just a note, Upcoming.org has fixed this on their end, they now use TZID:US-Pacific for the VTIMEZONE value.
You need to log in
before you can comment on or make changes to this bug.
Description
•