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)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bzuzga, Assigned: mostafah)

References

Details

Attachments

(1 file)

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.
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.
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
Attached file Minimal Fail Case —
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.
Attachment #123001 - Attachment mime type: application/octet-stream → text/calendar
This has been fixed in CVS and in the latest XPI ( May 8th 2003 ).
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Depends on: 124326
Fix in CVS unavailable for OS X users because of absence of fresh OS X installer. Added 
dependency to 124326.
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.

Attachment

General

Creator:
Created:
Updated:
Size: