error reading a remote calendar

VERIFIED INVALID

Status

Calendar
Provider: ICS/WebDAV
VERIFIED INVALID
10 years ago
10 years ago

People

(Reporter: Brian Millett, Unassigned)

Tracking

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
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

10 years ago
Created attachment 324062 [details]
original ics file

first ics file
(Reporter)

Comment 2

10 years ago
Created attachment 324064 [details]
ics if file #1 exported from webcalendar

This is the file that causes the error.
Attachment #324062 - Attachment mime type: text/calendar → text/plain
Attachment #324064 - Attachment mime type: text/calendar → text/plain

Updated

10 years ago
Component: Lightning Only → Provider: ICS/Webdav
QA Contact: lightning → ics-provider
Summary: error reading a remote calendar. → error reading a remote calendar
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

10 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
Last Resolved: 10 years ago
Resolution: --- → FIXED
Resolution: FIXED → INVALID
(Reporter)

Comment 6

10 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.

Comment 7

10 years ago
verified INVALID resolution.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.