User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20060426 Firefox/18.104.22.168 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.
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
Last Resolved: 13 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.