Closed Bug 437645 Opened 16 years ago Closed 16 years ago

error reading a remote calendar

Categories

(Calendar :: Provider: ICS/WebDAV, defect)

x86
Linux
defect
Not set
normal

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.
Attached file original ics file —
first ics file
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
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
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: 16 years ago
Resolution: --- → FIXED
Resolution: FIXED → INVALID
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.
verified INVALID resolution.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: