274464 - calIEvent.icalComponent.serializeToICS() outputs summary (and other fields), even when never set

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[Michiel van Leeuwen (email: mvl+moz@)]

getting the ics string from an event gives summary, priority, class, dtstart and
dtend while those were never set. It should not output them.

testcase:

var icsServ = Components.classes["@mozilla.org/calendar/ics-service;1"]
                        .createInstance(Components.interfaces.calIICSService);
var comp = icsServ.createIcalComponent("VCALENDAR");
var event = Components.classes["@mozilla.org/calendar/event;1"]
                      .createInstance(Components.interfaces.calIEvent);
dump(event.icalComponent.serializeToICS());

actual results:
BEGIN:VEVENT
CREATED:20041213T184159
LAST-MODIFIED:20041213T184159
SUMMARY:
PRIORITY:0
CLASS:PUBLIC
DTSTART:00000100T000000
DTEND:00000100T000000
DTSTAMP:20041213T184159
END:VEVENT

expected:
BEGIN:VEVENT
CREATED:20041213T184159
LAST-MODIFIED:20041213T184159
DTSTAMP:20041213T184159
END:VEVENT

(whitespaces removed. new libical version doesn't fix)

Comment 1

[Michiel van Leeuwen (email: mvl+moz@)]

(before you wonder: the missing Z after the datetime fields seem to be a problem
with my test new libical. It works in the currently used version)

Comment 2

[Mike Shaver (:shaver emeritus)]

This isn't a serialization bug, that I can see.  The calEvent has some things
that default to things like "0" for priority and "PUBLIC" for class.

Do we want to not have any defaults for these?

Comment 3

[Michiel van Leeuwen (email: mvl+moz@)]

I can live with a default priority, but i don't like the default dtstart and
dtend. a priorty of 0 makes some sense, but a start date of 0000-01-00? That's
quite some time ago...

Comment 4

[Mike Shaver (:shaver emeritus)]

Attachment: ensure initialization before enumerating

Comment 5

[Mike Shaver (:shaver emeritus)]

Comment on attachment 168743 [details] [diff] [review]
ensure initialization before enumerating

Sigh, wrong patch for this bug.

Comment 6

[Mike Shaver (:shaver emeritus)]

Fixed by the patch for 275070.