GNOME Bugzilla – Bug 649141
Return only system timezones known to libical
Last modified: 2013-09-14 16:55:26 UTC
Created attachment 187007 [details] Screenshot of the Problem The entries in the calendar in Evolution do not show up in the calendar applet of Gnome Shell. Steps to reproduce: add a new meeting to calendar, check the Gnome Shell applet to see if it shows up, it doesn't. Considering that this feature works well for everyone else, I'm not sure that's going to be very much help. I'm running Arch x86_64 and I update twice a day, so everything is the latest version out of the stable repositories.
I have the same problem too. Any hints how gnome-shell's calendar communicates with eds and how to debug?
OK I got this from ~/.xsession-errors (gnome-shell-calendar-server:5675): libecal-CRITICAL **: file e-cal.c: line 4155: assertion `zone' failed Error setting timezone on calendar: file e-cal.c: line 4155: assertion `zone' failed gnome-shell-calendar-server[5675]: Got HUP on stdin - exiting I fired up date time dialog, changed my timezone to a different one, then changed it back and gnome-shell's calendar now shows events in evolution.
Created attachment 198503 [details] [review] Print timezone lookup warning I have this problem again, with gnome-3.2, but more likely because I moved timezone. I have /etc/localtime with same content with /usr/share/zoneinfo/Australia/Melbourne, but some how ecal returns "Australia/Victoria" and the lookup routine fails. Anyway, can we have this patch in? It would help detect this kind of error
I have no idea about gnome-shell, but on the first look, your if (!zone) should rather check on if (!app->zone) as it's the place where zone is assigned a line in front of this newly added 'if'. Also note of this commit [1], though it's part of 3.2.0. [1] http://git.gnome.org/browse/evolution-data-server/commit/?id=505f9ef5d6ab0
Milan - this is basically an e-d-s bug - with the change you link to, when you have aliases like Australia/Melbourne (the Olson timezone name) and Australia/Victoria, the result of the e-d-s call will be based on readdir order. icaltimezone_get_builtin_timezone is defined to take an Olson timezone. There are ~440 Olson timezones, but GNU libc has ~1900 names for those 440 timezones. I'm uncertain how things in e-d-s are split and whether the read results could be cross-checked against libical's internal list, but that seems like the ideal thing to do. There's no real way that a user of libecal can recover if it gets some random alias for the timezone name.
(In reply to comment #5) > I'm uncertain how things in e-d-s are split and whether the read results could > be cross-checked against libical's internal list, but that seems like the ideal > thing to do. There's no real way that a user of libecal can recover if it gets > some random alias for the timezone name. If you receive an event as part of a VCALENDAR object, then it is supposed to contain also VTIMEZONE components for timezones used inside it. That's a way how the timezone is loaded into backend's cache. To get any timezone from the backend you simply call e_cal_client_get_timezone(). Adding events without timezone usually means to call e_cal_client_add_timezone() too. This way the event can have any timezone name, the backend is supposed to provide correct timezone object when asked for. Nonetheless my main comment was about Nguyen's patch.
(In reply to comment #6) > (In reply to comment #5) > > I'm uncertain how things in e-d-s are split and whether the read results could > > be cross-checked against libical's internal list, but that seems like the ideal > > thing to do. There's no real way that a user of libecal can recover if it gets > > some random alias for the timezone name. > > If you receive an event as part of a VCALENDAR object, then it is supposed to > contain also VTIMEZONE components for timezones used inside it. That's a way > how the timezone is loaded into backend's cache. To get any timezone from the > backend you simply call e_cal_client_get_timezone(). Adding events without > timezone usually means to call e_cal_client_add_timezone() too. This way the > event can have any timezone name, the backend is supposed to provide correct > timezone object when asked for. I'm confused here - the code in question does: location = e_cal_system_timezone_get_location (); if (location == NULL) app->zone = icaltimezone_get_utc_timezone (); else app->zone = icaltimezone_get_builtin_timezone (location); It's actually not completely clear to me how failure of the code above would result in no events showing up at all ... but you would agree that the code above does not work correctly witht he current implementation of e_cal_system_timezone_get_location(), right? > Nonetheless my main comment was about Nguyen's patch. I think your comment is right - the patch doesn't look like it would compile as written, but the patch is just a debugging patch, not necessarily something I'd land. Or are you suggesting that passing Australia/Victoria etc to altimezone_get_builtin_timezone() is fine and you mistrust the debugging result?
(In reply to comment #7) > It's actually not completely clear to me how failure of the code above would > result in no events showing up at all ... but you would agree that the code > above does not work correctly witht he current implementation of > e_cal_system_timezone_get_location(), right? I do not think it works correctly. It returned correct system timezone location. If the libical cannot find it then it's its issue, there is no control for evolution on it. I vaguely recall similar issue, and if I recall correctly then the libical upstream rejected any change. But it's quite long time ago, I can be wrong. > Or are you suggesting that passing Australia/Victoria etc to > altimezone_get_builtin_timezone() is fine and you mistrust the debugging > result? Nope, I trust debugging results. :) Based on comment #2, the call to e_cal_set_default_timezone() requires valid timezone object. If it's not there, then there left the default timezone, which is UTC. If the event's time, when converted to UTC, is out of the current time interval shown in the shell's calendar, then the events can be "missing". Unless the > gnome-shell-calendar-server[5675]: Got HUP on stdin - exiting means that the gnome-shell-calendar-server killed itself on a runtime error/warning printout, which seems rather silly.
(In reply to comment #8) > I do not think it works correctly. It returned correct system timezone > location. If the libical cannot find it then it's its issue, there is no > control for evolution on it. I'd appreciate some sort of notification when this happens, either from Evolution or gnome-shell. People expect it to get correct time zone, if it can't it should do something. > Nope, I trust debugging results. :) Based on comment #2, the call to > e_cal_set_default_timezone() requires valid timezone object. If it's not there, > then there left the default timezone, which is UTC. If the event's time, when > converted to UTC, is out of the current time interval shown in the shell's > calendar, then the events can be "missing". Unless the Something gnome-shell can fix here maybe? To show all entries? The time would be wrong (due to timezone falling back to UTC), which could be an indication something is not right.
Created attachment 206420 [details] [review] eds patch for evolution-data-server; This makes e_cal_system_timezone_get_location() return only those timezones, which are known to libical (which are those written in /user/share/zoneinfo/zone.tab). It also makes sure that the fallback timezone (on the recursive lookup) is rewritten only with libical known timezone. In your case won > Australia/Victoria on > Australia/Melbourne only because it's shorter. Do not ask me why there was used such heuristic. Currently, the first libical known timezone wins.
Created commit d116cf8 in eds master (3.3.5+)