After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 155206 - Task Bar Calendar shows evolution task with wrong time (timezone related)
Task Bar Calendar shows evolution task with wrong time (timezone related)
Product: gnome-panel
Classification: Other
Component: clock
Other Linux
: High major
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Reported: 2004-10-12 16:47 UTC by Gerardo Marin
Modified: 2020-11-06 20:22 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Gerardo Marin 2004-10-12 16:47:50 UTC
This was filed as
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 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.
Comment 1 William Jon McCann 2004-10-12 21:26:52 UTC
Do you have an example?  I'm not able to reproduce this.  Thanks.
Comment 2 Christian Neumair 2004-10-21 13:25:33 UTC
This could be a duplicate of bug 149503, or at least be related to that bug.
Comment 3 Vincent Untz 2005-01-05 11:34:47 UTC
Gerardo: do you have an exeample?
Comment 4 Sebastien Bacher 2005-07-17 01:18:38 UTC
can you reply? do you still have this issue?
Comment 5 Olav Vitters 2005-12-29 17:20:45 UTC
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.
Comment 6 Sven Arvidsson 2007-03-31 17:57:34 UTC
[ Forwarded from Debian ]

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 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.

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.
Comment 7 Hongzheng Wang 2007-04-27 08:41:31 UTC
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.
Comment 8 Hongzheng Wang 2007-04-28 03:14:22 UTC
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.
Comment 9 Andrew Bettison 2008-02-29 10:09:30 UTC
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. 

PRODID:-//Google Inc//Google Calendar 70.9054//EN
X-WR-CALNAME:Andrew Bettison
LOCATION:Casa de la Cerveza - Luchana 15\, Metro Bilbao - UPSTAIRS
SUMMARY:Australian Alumni Meeting
Comment 10 André Klapper 2009-12-19 21:41:56 UTC
So, does anybody still see this in a recent version of GNOME, like 2.28?
Comment 11 Andrew Bettison 2010-02-08 14:20:23 UTC
I no longer have this issue in GNOME Clock applet 2.28.0.  Google Calendar times are now correct.
Comment 12 André Klapper 2020-11-06 20:22:32 UTC is being replaced by 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

Thank you for reporting this issue and we are sorry it could not be fixed.