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 690930 - Launching calendar from clock-applet applies timezone twice
Launching calendar from clock-applet applies timezone twice
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
3.6.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2012-12-31 21:02 UTC by Tristan Schmelcher
Modified: 2013-03-12 11:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
evo patch (1.80 KB, patch)
2013-03-12 11:32 UTC, Milan Crha
committed Details | Review

Description Tristan Schmelcher 2012-12-31 21:02:49 UTC
Upstreaming from https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1025087

In Evolution 3.6.0 (and also 3.2.3), double-clicking a date in the calendar applet consistently opens the previous day in Evolution for me. Looking in "ps", the calendar applet is launching Evolution with this command-line for July 25:

evolution calendar:///?startdate=20120725T080000Z

I am in the America/Los_Angeles timezone which is GMT -8 or GMT -7 during DST, so that seems to be a valid date string for July 25 (8 AM GMT is 1 AM PDT or 12 AM PST, either of which should mean July 25), but Evolution interprets it as meaning July 24. By trial and error, I found that the threshold where it will start opening July 25 is 20120725T140000Z, i.e. July 25 at 2 PM. For December 1, the threshold is 20121201T160000Z, i.e. December 1 at 4 PM. The significance to this is that the offset of 14 in the summer is 7 * 2 and the offset of 16 in the winter is 8 * 2, so it appears that Evolution is incorrectly applying the time zone subtraction twice.
Comment 1 Milan Crha 2013-03-12 11:32:13 UTC
Created attachment 238683 [details] [review]
evo patch

for evolution;

The problem was with g_date_set_time_t(), which expects a UTC time, and converts it into localtime(), while evolution expects time in the timezone set in evolution, which can be different from the system timezone. This way one conversion was done in evolution itself, then in g_date_set_time_t(). Avoiding usage of g_date_set_time_t() helps here.
Comment 2 Milan Crha 2013-03-12 11:34:29 UTC
Created commit 3e8e8cb in evo master (3.7.92+)