Hello! I've started testing a version of SyncEvolution which uses the EBook/CalClient API. The import test fails for a VEVENT which uses a custom timezone:
BEGIN:VCALENDAR PRODID:-//Ximian//NONSGML Evolution Calendar//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:EST/EDT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19671029T020000 RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19870405T020000 RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=1SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:20060416T205224Z-4272-727-1-251@gollum DTSTAMP:20060416T205224Z DTSTART;TZID=EST/EDT:20060406T140000 DTEND;TZID=EST/EDT:20060406T143000 TRANSP:OPAQUE SEQUENCE:2 SUMMARY:timezone New York with custom definition for 2006 CLASS:PUBLIC CREATED:20060416T205301Z LAST-MODIFIED:20120531T085920Z END:VEVENT END:VCALENDAR e_cal_client_check_timezones() fails with "Could not retrieve calendar time zone: Invalid object". This comes from the attempt to look up "EST/EDT" in an empty calendar: icaltimezone * e_cal_client_tzlookup (const gchar *tzid, gconstpointer ecalclient, GCancellable *cancellable, GError **error) { ... if (e_cal_client_get_timezone_sync (cal_client, tzid, &zone, cancellable, &local_error)) { g_warn_if_fail (local_error == NULL); return zone; } if (g_error_matches (local_error, E_CAL_CLIENT_ERROR, E_CAL_CLIENT_ERROR_OBJECT_NOT_FOUND)) { /* We had to trigger this error to check for the * timezone existance, clear it and return NULL. */ g_clear_error (&local_error); } ... It's normal that e_cal_client_get_timezone_sync() fails. But it fails with an unexpected error: signal sender=:1.3 -> dest=(null destination) serial=94 path=/org/gnome/evolution/dataserver/Calendar/1636/9; interface=org.gnome.evolution.dataserver.Calendar; member=get_timezone_done uint32 18 string "org.gnome.evolution.dataserver.Calendar.InvalidObject" string "Could not retrieve calendar time zone: Invalid object" string "" Therefore the error is not cleared and e_cal_client_check_timezones() aborts instead of accepting the "EST/EDT" time zone as it is. This works in Evolution itself, probably because it let's the backend itself do the e_cal_client_check_timezones() with a different lookup function. What is the preferred way of fixing this? We could define that e_cal_client_get_timezone*() must return the E_CAL_CLIENT_ERROR_OBJECT_NOT_FOUND error when the time zone doesn't exist and fix it to do so. Or we could make the error check in e_cal_client_tzlookup() more liberal and ignore all E_CAL_CLIENT_ERRORs. The latter might be easier, in particular considering that multiple different calendar backends might need fixing to reliably return E_CAL_CLIENT_ERROR_OBJECT_NOT_FOUND. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers