Closed
Bug 317307
Opened 19 years ago
Closed 19 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•19 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: 19 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•19 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
•