GNOME Bugzilla – Bug 711658
Time zone for new events sometimes defaults to UTC
Last modified: 2014-03-06 14:37:25 UTC
Sometimes, when I create a new event, the time zone is set to UTC and the time zone bar is visible while it's normally hidden. I need to set manually my time zone to the system time zone to fix this. This is quite dangerous: the first time I did not notice it and the time of the event was incorrect. In the preferences, I have checked "Use system time zone (Europe/Paris)". More precisely, it seems that the bug happens only the first time I open the window to create a new event. The second time is fine. The bug reappears if I restart Evo. FWIW, another interesting point is that in the Display menu when creating a new even, "Time zone" is not checked: this means I need to check and uncheck it again to get the time zone bar to disappear. Maybe this is the sign of a GSettings synchronization issue? e.g. if the bar appears before the settings are set, it starts with the default value UTC. This is with Evo 3.8.5 on Fedora 19.
Confirming, it's still there, current git master (after 3.11.91 release). My reproducer is: a) run evolution in mailer (evolution -c mail) b) File->New->Appointment * it opens with UTC time zone c) close it and repeat File->New->Appointment * it opens with the system timezone
The problem was with the EClientCache and its "client-created" signal, to which connected ESettingsClientCache, and the fact that this signal is emitted on idle, instead of immediately. The cal_comp_event_new_with_current_time() used client's default timezone to determine what time to set, but when the new component was called with steps from comment #1, then the first ECalClient was created, which didn't have set the default timezone, thus it was left in UTC. The ECalClient's default timezone was changed only after the dialog with a new event was opened, which is too late. I added a new signal, EClientCache::client-connected, which is fired immediately, and let the ESettingsClientCache connect to it instead. I also changed couple other places which used e_cal_client_get_default_timezone() to read preferred timezone from the settings, rather then rely on the ECalClient property. This may avoid the issue in the future. Created commit 3048de0 in evo master (3.11.92+) https://git.gnome.org/browse/evolution/commit/?id=3048de0