Closed
Bug 437645
Opened 17 years ago
Closed 17 years ago
error reading a remote calendar
Categories
(Calendar :: Provider: ICS/WebDAV, defect)
Tracking
(Not tracked)
VERIFIED
INVALID
People
(Reporter: bmillett, Unassigned)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5
Build Identifier: lighting 0.9pre build 2008060418
This is very strange. I can take the ics file and load it into a local lightning calendar and it works fine. I can export the lightning calendar as an ics file and load it into the remote calendar (WebCalendar v1.2.b1 (25 Feb 2008)) and it works find using the webcalendar web interface. I try to subscribe to the calendar remotely, and I get the following error reading from the remote interface. I export the calendar from webcalendar and I cannot load that export into lightning. I get the same error below:
Error: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [calIIcalComponent.endTime]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: file:///home/bpm/.thunderbird/default/e4xceiin.slt/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js :: anonymous :: line 553" data: no]
Source File: file:///home/bpm/.thunderbird/default/e4xceiin.slt/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js
Line: 553
Reproducible: Always
Steps to Reproduce:
1.subscribe to remote calendar
2.refresh calendar
3.read error
I can send the two ics files. 1) that loads into lightning and 2) export of (1) from webcalendar, but I do not see howto.
Reporter | ||
Comment 1•17 years ago
|
||
first ics file
Reporter | ||
Comment 2•17 years ago
|
||
This is the file that causes the error.
Updated•17 years ago
|
Attachment #324062 -
Attachment mime type: text/calendar → text/plain
Updated•17 years ago
|
Attachment #324064 -
Attachment mime type: text/calendar → text/plain
Updated•17 years ago
|
Component: Lightning Only → Provider: ICS/Webdav
QA Contact: lightning → ics-provider
Summary: error reading a remote calendar. → error reading a remote calendar
Comment 3•17 years ago
|
||
Both .ics file fail on the iCalendar Validator <http://severinghaus.org/projects/icv/>.
The errors occurs on events like (from attachment 324064 [details]):
BEGIN:VEVENT
UID:20080504T0001004645109@lds.org
LAST-MODIFIED:20080529T031702Z
SUMMARY:Elder Russell M. Nelson
DESCRIPTION:Elder Russell M. Nelson
CATEGORIES:Branch Event
CLASS:PUBLIC
STATUS:CONFIRMED
ATTENDEE;ROLE=OWNER;PARTSTAT=ACCEPTED:Brian Millett <xxx@yyy.zzz>
DTSTART;TZID=America/Chicago:20080504T000000
DTSTAMP:20080529T121243Z
DTEND;VALUE=DATETIME:20080505T000000
END:VEVENT
The line that causes the failure is
DTEND;VALUE=DATETIME:20080505T000000
The line doesn't exist in the first file (attachment 324062 [details]) and has been added by WebCalendar application. I think this is invalid according to RFC2445. The correct entry should be
DTEND;VALUE=DATE-TIME:20080505T000000
Reporter | ||
Comment 4•17 years ago
|
||
Very NICE! I fixed the webcalendar code found in xcal.php. I changed the DATETIME to be DATE-TIME and it now works. Interesting in that in the xcal code there is this comment:
// All times are now stored in UTC time, so no conversions are needed
// other than formatting
//
// NOTE: Forcing the DTEND to include a 'T000000' as a DATETIME rather
// than just a DATE is needed to avoid a bug in Sunbird 0.7. If the
// DTSTART has a DATETIME and the DTEND is just DATE, then Sunbird locks up.
I'll notify the webcalendar people.
Thanks!! So very fast!
You might want to have a bit of an ability to see just what line it did croak on, or what data structure, not just the js line.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Resolution: FIXED → INVALID
Comment 5•17 years ago
|
||
Corresponding WebCalendar bug report: https://sourceforge.net/tracker/index.php?func=detail&aid=1960454&group_id=3870&atid=103870
Reporter | ||
Comment 6•17 years ago
|
||
Looks like they took a different approach to solve it. The cvs co of the 1.2 branch shows that they just are going to use DATE.
$ret .= "DTEND;VALUE=DATE:$date\r\n";
Thanks for the quick reply.
You need to log in
before you can comment on or make changes to this bug.
Description
•