Closed
Bug 192791
Opened 22 years ago
Closed 21 years ago
All-day events exported from Apple's iCal span two days
Categories
(Calendar :: Sunbird Only, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bzuzga, Assigned: mostafah)
References
Details
Attachments
(1 file)
475 bytes,
text/calendar
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 Looks like there is a small difference between the exact representation of holidays between RFC2445, Mozilla's implementation, and Apple's implementation. This manifests itself only when going from Apple's format to Mozilla's calendar frontend. The Apple all-day events and holidays end at midnight the next day, while Mozilla's end at 23:59:00. When displaying an all-day event exported from Apple's iCal, it appears to span two days in Mozilla's front end. The RFC seems to indicate that an end time isn't required. This is an interesting interoperability issue, and I'm not really sure what the best interpretation of the RFC is. Example from RFC2445 section 4.6.1: BEGIN:VEVENT UID:19970901T130000Z-123403@host.com DTSTAMP:19970901T1300Z DTSTART:19971102 SUMMARY:Our Blissful Anniversary CLASS:CONFIDENTIAL CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION RRULE:FREQ=YEARLY END:VEVENT Example from http://www.mozilla.org/projects/calendar/caldata/USHolidays.ics BEGIN:VCALENDAR VERSION :2.0 PRODID :PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN BEGIN:VEVENT UID :969759024 SUMMARY :*New Year's Day CLASS :PRIVATE X ;MEMBER=AllDay :TRUE X ;MEMBER=AlarmUnits :minutes X ;MEMBER=AlarmLength :15 X ;MEMBER=RecurUnits :years X ;MEMBER=RecurInterval :1 RRULE :FREQ=YEARLY;INTERVAL=1;BYMONTH=1 DTSTART :20020101T000000 DTEND :20020101T235900 END:VEVENT END:VCALENDAR Example from webcal://ical.mac.com/ical/US32Holidays.ics BEGIN:VEVENT DTSTAMP:20020822T225358Z SUMMARY:New Year's Day UID:C16CDDEA-C800-11D6-B5FC-003065F198AC RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=1 DTSTART;VALUE=DATE:20020101 DTEND;VALUE=DATE:20020102 END:VEVENT Reproducible: Always Steps to Reproduce: 1. Subscribe to Apple's US Holidays using the 20030210 build of calendar: http://ical.mac.com/ical/US32Holidays.ics 2. Pull up the month or week views. Actual Results: Note that most of the holidays span two days in the visual rendering. Expected Results: The holiday should appear on one and only one day.
Reporter | ||
Comment 1•22 years ago
|
||
From section 6 in the RFC: 2. A calendar entry with a "DTSTART" property but no "DTEND" property does not take up any time. It is intended to represent an event that is associated with a given calendar date and time of day, such as an anniversary. Since the event does not take up any time, it MUST NOT be used to record busy time no matter what the value for the "TRANSP" property.
Comment 2•22 years ago
|
||
This is a problem with ambiguity in the spec, however I think that Apple is right.
Assignee: mikep → mostafah
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•21 years ago
|
||
I am also experiencing this problem with my calendar of birthdays. Looks fine under Apple iCal where it was created. I have extracted a single event, my own birthday, to a separate calendar file and submitted here in hopes of providing a minimal test case. When rendered properly, it should appear as an all day event every February 21.
Updated•21 years ago
|
Attachment #123001 -
Attachment mime type: application/octet-stream → text/calendar
Assignee | ||
Comment 4•21 years ago
|
||
This has been fixed in CVS and in the latest XPI ( May 8th 2003 ).
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 5•21 years ago
|
||
Fix in CVS unavailable for OS X users because of absence of fresh OS X installer. Added dependency to 124326.
Comment 6•18 years ago
|
||
The bugspam monkeys have been set free and are feeding on Calendar :: Sunbird Only. Be afraid for your sanity!
QA Contact: gurganbl → sunbird
You need to log in
before you can comment on or make changes to this bug.
Description
•