Description of problem: when Copy from Calander Day view, and paste in Calander, it is ok, but when you paste that data in Gedit, it is showing complete Locale information, as given below ------------ BEGIN:VCALENDAR CALSCALE:GREGORIAN PRODID:-//Ximian//NONSGML Evolution Calendar//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:/softwarestudio.org/Olson_20011030_5/Asia/Calcutta X-LIC-LOCATION:Asia/Calcutta BEGIN:STANDARD TZOFFSETFROM:+0530 TZOFFSETTO:+0530 TZNAME:IST DTSTART:19700101T000000 END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:20060807T082151Z-13718-500-1-2.redhat.com DTSTAMP:20060807T082151Z DTSTART;TZID=/softwarestudio.org/Olson_20011030_5/Asia/Calcutta: 20060807T110000 DTEND;TZID=/softwarestudio.org/Olson_20011030_5/Asia/Calcutta: 20060807T113000 SUMMARY:dd333 CREATED:20060807T082156 LAST-MODIFIED:20060807T082156 END:VEVENT END:VCALENDAR --------------------- Version-Release number of selected component (if applicable): evolution-2.7.4-4 How reproducible: Everytime, during copy and paste for Calander to some other application Steps to Reproduce: 1.Open Evolution 2.goto Calander->Day View 3. type something and copy that 4. Paste now in Gedit Actual results: Unexpected date is pasted in gedit Expected results: same data should paste as copied Additional info: copy from gedit and paste in Gedit is not working as per bug 198425 ([cal]C 'n' P is not working DayView)
This is how I'm able to reproduce it on [majain@majain ~]$ evolution --version Gnome evolution-2.8 2.7.4 1) Start evo & switch to cal, day view 2) type "abc" in any text widget, select it with <shift>+<home> 3) Paste in gedit --> "abc" is pasted 4) Type "abc" in another text widget in evo cal, & repeat (2) 5) Paste it in gedit & the LOCALE data as metioned in bug report gets pasted. Aalam, can you please verify your steps (and mine) to reproduce & tell which one to follow? Thanks, Mayank
Okay, confirmed that original steps work.
tested with following version: evolution-2.7.91-1
Upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=350561
Closing as UPSTREAM since this bug report was already forwarded upstream. I will continue to track the problem there.