GNOME Bugzilla – Bug 611558
e_cal_check_timezones() + could not retrieve calendar time zone
Last modified: 2017-08-31 11:31:44 UTC
Created attachment 155007 [details] self-contained test program There seems to be a regression in the calendar time zone support, caused by the migration to D-Bus. This was originally found in Moblin, which according to Ross Burton uses the upstream EDS. I have not verified whether it fails with the latest upstream sources (not compiled). To reproduce the problem, compile with: gcc -Wall -g `pkg-config --cflags libecal-1.2` `pkg-config --libs libecal-1.2` fix-timezone.c -o fix-timezone Then run it as ./fix-timezone. It will create a calendar in /tmp/fix-timezone-cal. With EDS 2.28.x, it works and prints "okay". On Moblin Trunk, it creates the calendar, then prints "failed: Could not retrieve calendar time zone".
Created attachment 157476 [details] [review] add E_CALENDAR_STATUS_INVALID_OBJECT handling Root cause: error returned for "timezone cannot be retrieved because it doesn't exist" no longer sets the same error codes as previous releases. e-cal-check-timezones.c: 475 g_assert(*error); 476 if ((*error)->domain == E_CALENDAR_ERROR && 477 (*error)->code == E_CALENDAR_STATUS_OBJECT_NOT_FOUND) { 478 /* 479 * we had to trigger this error to check for the timezone existance, (gdb) p (*error) $5 = (GError *) 0x61d800 (gdb) p (**error) $6 = {domain = 115, code = 6, message = 0x621aa0 "Could not retrieve calendar time zone"} Code = 6 = E_CALENDAR_STATUS_INVALID_OBJECT. Fix is in the attached patch.
Thanks for a bug report and the patch. It seems I caused this when rewriting timezone handling, one thing I didn't realize. The issue here is that the e_cal_backend_internal_get_timezone is always returning a timezone, a UTC, when didn't find the asked for. The other problem is that the UTC zone has no component, thus the icaltimezone_get_component in e_cal_backend_sync_get_timezone fails and function returns invalid object; though it's probably not a problem, but an advantage. How to return UTC here? Or is it enough to return "not found" and that's it? Anyway, I believe the correct fix would be to count with UTC in e_cal_backend_sync_get_timezone and return not-found for it when returned by e_cal_backend_internal_get_timezone. Could you update your patch, please?
I tested the attached self-test, and adapted it to current sources, and it returns okay now too (3.25.91), thus I'm closing this.