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 615497 - Pilot calendar, todo fail to sync because timezone is set too early
Pilot calendar, todo fail to sync because timezone is set too early
Status: RESOLVED DUPLICATE of bug 611646
Product: evolution
Classification: Applications
Component: Do Not Use
2.30.x (obsolete)
Other Linux
: Normal major
: ---
Assigned To: Veerapuram Varadhan
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2010-04-12 07:44 UTC by Matt McCutchen
Modified: 2013-09-13 12:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix that seems to work (2.70 KB, patch)
2010-04-12 07:44 UTC, Matt McCutchen
rejected Details | Review

Description Matt McCutchen 2010-04-12 07:44:13 UTC
Created attachment 158464 [details] [review]
Fix that seems to work

The calendar and todo applications on my pilot do not sync with Evolution (memo is unaffected).  The symptom is the same as in bug 611860.

I ran gpilotd under a debugger and saw that the timezone code is at fault again.  Ugggh!  The respective "start_calendar_server" functions for the calendar and todo conduits try to set the timezone of the calendar before opening it.  That may have worked in the past, but in Evolution 2.30, it hits the following check in e_cal_set_default_timezone:

	if (priv->load_state != E_CAL_LOAD_LOADED) {
		E_CALENDAR_CHECK_STATUS (E_CALENDAR_STATUS_URI_NOT_LOADED, error);
	}

In the start_calendar_server functions, I moved the e_cal_set_default_timezone call after e_cal_open and now syncing works again.  My patch is attached, but there is probably more cleanup that could or should be done.
Comment 1 Milan Crha 2010-04-27 11:54:07 UTC
Thanks for a bug report and the patch, your observation is correct, but this has been fixed very recently, as part of bug #611646, where the above 'if' statement was removed. I'm marking this one as a duplicate of it.

*** This bug has been marked as a duplicate of bug 611646 ***