GNOME Bugzilla – Bug 238346
Copy&paste of events in week view removes timezone info
Last modified: 2013-09-10 14:04:26 UTC
Description of Problem: In the week/month view, I copied an event that has a timezone different than my native one. Then I pasted it on another day and the time of the new event was correct but it was offset to the local timezone. It should keep the original timezone, I think. Steps to reproduce the problem: 1. Set your timezone to Mexico City. 2. Create an event with a New York timezone. 3. Go to the week view. 4. Right-click on the event and Copy it. 5. Right-click on another day and Paste. Actual Results: The event gets pasted in the new day correctly and at what would be the correct local time (e.g. 11:00 in Mexico City while the original event was at 12:00 in New York). However, it uses the local timezone (Mexico City) rather than the original one (New York). Expected Results: The event would get the original timezone. How often does this happen? Every time. It doesn't happen on the day view, however, which does keep the original timezone. Additional Information: I'm using Evo 1.2.1.99.
Still an issue in 1.5.94
*** bug 268420 has been marked as a duplicate of this bug. ***
very related to bug 245156, if this gets solved please copy the code to also solve bug 245156... ;-)
Hmm, this does happen on the day view as well and is intentional. Referring to product design as part of a calendar view refresh in 2.3
uhm... even worse in 2.7.3 - the time zone info gets removed, but the time itself does not get converted, so the appointment will be displayed at the original timezone time, but not my timezone time. i can miss appointments because of that.
Bumping version to a stable release.
Created attachment 119402 [details] [review] proposed evo patch for evolution; Keep old timezones if possible.
The patch looks fine if the oldtimezone is one of the libical timezones. In case if the timezone is not in libical (such as exchange timezones), old_dtstart.zone might be NULL. We might have to use the tzid parameter to get the timezone from the backend. Have you tested moving appointments which has a exchange timezone in it ?
Created attachment 127774 [details] [review] proposed evo patch ][ for evolution; Right, it didn't work there. Mainly because the timezone from the source calendar wasn't known for the destination calendar. This fixes it. As you asked in the other bug, those two cycles could be done in one, but I intentionally do this in two, as my comment above the timezone cycle says: /* add timezones first, to have them ready */
The parts in if (!e_cal_get_timezone (client, tzid, &zone, &error)) { inside add_related_timezones can be swapped for clarity. say if (e_cal_get_timezone) { } else {print error}. Please make these changes and commit the patch.
I do not agree with that change, really, it would be with your request: if (e_cal_get_timezone ()) { if (zone && ...) { ... } } else { print err } The actual code seems to me much clearer. But as you mentioned on IRC, DTSTAMP is supposed to be in UTC, thus I'm going to remove this one from list of items to check.
Slightly modified committed to trunk. Committed revision 37337.
Once e_cal_get_timezone succeeds, you need to check if (zone) at all.