GNOME Bugzilla – Bug 155206
Task Bar Calendar shows evolution task with wrong time (timezone related)
Last modified: 2020-11-06 20:22:32 UTC
This was filed as http://bugzilla.ximian.com/show_bug.cgi?id=67209 Distribution: SuSE Linux 9.1 (i586) Package: Evolution Priority: Major Version: GNOME2.8.0 2.0.0 Gnome-Distributor: GNOME.Org Synopsis: Task Bar Calendar shows evolution task with wrong time (timezone related) Bugzilla-Product: Evolution Bugzilla-Component: Calendar Bugzilla-Version: 2.0.0 Description: Description of Problem: When adding a iCalendar object from a different timezone, received via email, to Evolution's calendar, the calendar in the gnome task bar will not show the time of the event in the user's timezone but in the timezone of the person who sent the email. Evolution itself does display the event in the correct time slot for your timezone but the taskbar calendar does not. This can be very confusing for people who use the gnome taskbar calendar to track events. Steps to reproduce the problem: 1. Receive an email with an iCalendar from a person in another timezone 2. Accept the icalendar event and add it to your calendar. 3. Open up evolution and look at the event in your calendar. 4. Note the time slot of the event (will be correct for your timezone, not the timezone of the email sender) 5. Use the taskbar calendar and look at the event listed. 6. Note that the time listed is not for your timezone but the timezone of the sender of the email.
Do you have an example? I'm not able to reproduce this. Thanks.
This could be a duplicate of bug 149503, or at least be related to that bug.
Gerardo: do you have an exeample?
can you reply? do you still have this issue?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
[ Forwarded from Debian ] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401043 Reopening bug as some Debian users have reported this bug, and I can reproduce it. I'm running gnome-panel 2.16.3 and evolution 2.8.2.1. My time zone is Europe/Stockholm (GMT +1 hour), but currently GMT +2 hours because of DST. After adding the below calenda, the appointments correctly show up as 19:30 (Schnupperkurs) and 21:00 (Swing on Sunday) for April 1 in Evolution. In the panel calendar they are listed as 21:30 and 23:00. In Evolution the appointments are marked with the timezone icon, but the timezone field is blank if I double click an appointment and try to view the details. http://www.google.com/calendar/ical/29bdp3b45vo3132rtfbsqkg4io%40group.calendar.google.com/public/basic.ics I have also seen this for appointments added to my local calendar. The appointments I added last week do not have any timezone set, but correctly show up in Evolution as 09:00, they are shown as 10:00 in the panel calendar. Setting the timezone manually for these corrects the behaviour. Couriosly, if I add an appointment now, the timezone is set and the appointment show up correct in both Evo and the panel calendar.
I have encountered the same problem. I'm running gnome-panel 2.18.1 and evolution 2.10.1, and the timezone is Asia/Hong_Kong (GTM +8). With Google Calendar (timezone is also set to Hong_Hong), suppose I appoint a event at 3:30 pm Apr 24, the evolution calendar displays it correctly. But in gnome-panel clock applet, the time is incorrectly marked as 11:30 pm Apr 24, i.e., eight hours later. However, this problem does not occure in local evolution calendar. Really strange.
Sorry for my comment #7. It seems that this bug has disappeared in evolution 2.10.1. When I composed comment #7 yesterday, I had just upgraded evolution to 2.10.1 (evolution-data-server upgraded to 1.10.1). Since I forgot to restart e-d-s, an incorrect result was obtained. Looking forward to seeing others' confirmations.
I experience the same problem in gnome-panel clock applet 2.20.3 (Debian lenny). My timezone is GMT+1 (Spain in winter). I have a Google Calendar with an appointment in Madrid for 8 pm (20:00). In the clock applet, the appointment time is shown as 9 pm (21:00). All appointment times from the same Google Calendar suffer the same offset. I don't use Evolution. I have evolution-data-server 1.12.3 installed. I used evolution-webcal 2.12.0 to subscribe to the Google Calendar private URL. The ICAL feed from that URL is below. Note that the DTSTART and DTEND lines inside the VEVENT section specify TZID=Europe/Madrid. My hypothesis is that the calendar parsing library used in the clock applet is not parsing this TZID correctly, and just falling back to assuming that the start and end times are in UTC. BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH X-WR-CALNAME:Andrew Bettison X-WR-TIMEZONE:Europe/Madrid BEGIN:VTIMEZONE TZID:Europe/Madrid X-LIC-LOCATION:Europe/Madrid BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID=Europe/Madrid:20080307T200000 DTEND;TZID=Europe/Madrid:20080307T230000 DTSTAMP:20080229T100257Z UID:l7t462nk3bmkiprr01kksa5re0@google.com CLASS:PRIVATE CREATED:20080228T205015Z DESCRIPTION: LAST-MODIFIED:20080228T205130Z LOCATION:Casa de la Cerveza - Luchana 15\, Metro Bilbao - UPSTAIRS SEQUENCE:1 STATUS:CONFIRMED SUMMARY:Australian Alumni Meeting TRANSP:OPAQUE END:VEVENT END:VCALENDAR
So, does anybody still see this in a recent version of GNOME, like 2.28?
I no longer have this issue in GNOME Clock applet 2.28.0. Google Calendar times are now correct.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.