iCalendar data pasted from clipboard is not parsed like imports

VERIFIED FIXED

Status

VERIFIED FIXED
13 years ago
13 years ago

People

(Reporter: rduke15, Assigned: jminta)

Tracking

({dataloss})

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 1

13 years ago
Created attachment 223018 [details]
Screen capture with both events: imported and pasted
Keywords: dataloss
(Assignee)

Comment 2

13 years ago
Created attachment 224485 [details] [diff] [review]
check for isDate

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+
(Assignee)

Comment 4

13 years ago
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
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 5

13 years ago
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.