Closed Bug 338957 Opened 14 years ago Closed 14 years ago

iCalendar data pasted from clipboard is not parsed like imports

Categories

(Calendar :: Internal Components, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: rduke15, Assigned: jminta)

References

()

Details

(Keywords: dataloss)

Attachments

(2 files)

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.
Attached patch check for isDateSplinter Review
We should check for isDate on the old date when we figure out what day to paste the event into.
Assignee: base → jminta
Status: UNCONFIRMED → ASSIGNED
Attachment #224485 - Flags: first-review?(mvl)
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
Attachment #224485 - Flags: first-review?(mvl) → first-review+
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>
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060824 Calendar/0.3a2+
(In reply to comment #5)
--> VERIFIED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.