Closed Bug 317307 Opened 15 years ago Closed 15 years ago

Errors when subscribing to calendar

Categories

(Calendar :: General, defect)

PowerPC
macOS
defect
Not set
normal

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
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: 15 years ago
Resolution: --- → INVALID
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.