338957 - iCalendar data pasted from clipboard is not parsed like imports

Status: VERIFIED FIXED

(Calendar :: Internal Components, defect)

Description

[M]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060518 Mozilla Sunbird/0.3a2+

When you have iCalendar text data in the clipboard and paste it into Sunbird, it is not treated the same way as if you import the same data from a file, or subscribe to it.

Particularly, all day events with no time or time zone specification are not seen as all day events. They get interpreted as 00:00 GMT and converted to local time. 

This only happens when pasting from the clipboard, not when importing the same data, or subscribing to it.


Reproducible: Always

Steps to Reproduce:
1. Import or subscribe to the file at http://alma.ch/cal/allday-test.ics

2. Copy this identical (except summary) text to the clipboard:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Whatever/NONSGML x V0.1//EN
BEGIN:VEVENT
DTSTART;VALUE=DATE:20060524
DTEND;VALUE=DATE:20060525
DTSTAMP:20060520T000000Z
SUMMARY:All Day event test pasted from clipboard
END:VEVENT
END:VCALENDAR

3. Paste into Sunbird

Actual Results:  
If you are not in GMT, the pasted event is spanning 2 days, from xx:00 to xx:00 (xx being your local time zone offset), while the identical imported event is correct.

Expected Results:  
Should be the same as when importing the file through File->Import or subscribing to the remote calendar: an All Day event for May 24, 2006.

Also, when you hover over both (pasted or imported) events, the popup still shows an irrelevant local time. But this looks like a separate (and mostly cosmetic) bug.

Comment 1

[M]

Attachment: Screen capture with both events: imported and pasted

Comment 2

[Joey Minta]

Attachment: check for isDate

We should check for isDate on the old date when we figure out what day to paste the event into.

Comment 3

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

Comment on attachment 224485 [details] [diff] [review]
check for isDate

Can you double-check that you should normalize before setting isDate? (I'm not sure what is right atm, it might not even make a difference)

r=mvl after you checked

Comment 4

[Joey Minta]

Patch checked in.

It doesn't seem to matter when normalize(); is called

js> var cdt1 = Components.classes["@mozilla.org/calendar/datetime;1"].createInstance(Components.interfaces.calIDateTime);
js> cdt1.jsDate = new Date();
Mon Jun 19 2006 09:46:37 GMT-0700 (PDT)
js> cdt1.day = 43;
43
js> cdt1.normalize();
js> cdt1
2006/07/13 16:46:37 UTC
js> cdt1.isDate = true;
true
js> cdt1;
2006/07/13 00:00:00 UTC
js> var cdt2 = Components.classes["@mozilla.org/calendar/datetime;1"].createInstance(Components.interfaces.calIDateTime);
js> cdt2.jsDate = new Date();
Mon Jun 19 2006 09:47:27 GMT-0700 (PDT)
js> cdt2.day = 43;
43
js> cdt2.isDate = true;
true
js> cdt2.normalize();
js> cdt2;
2006/07/13 00:00:00 UTC
js>

Comment 5

[Damian Szczepanik]

verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060824 Calendar/0.3a2+

Comment 6

[Stefan Sitter [:ssitter]]

(In reply to comment #5)
--> VERIFIED