GNU bug report logs -
#35746
Evolution calendar gets the timezone wrong
Previous Next
Reported by: Ben Sturmfels <ben <at> sturm.com.au>
Date: Wed, 15 May 2019 13:18:01 UTC
Severity: normal
Done: Ben Sturmfels <ben <at> sturm.com.au>
Bug is archived. No further changes may be made.
Full log
Message #32 received at 35746 <at> debbugs.gnu.org (full text, mbox):
Hi again,
Timothy Sample <samplet <at> ngyro.com> writes:
> Hello,
>
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hi Ben,
>>
>> Ben Sturmfels <ben <at> sturm.com.au> skribis:
>>
>>> In Evolution though, all my calendar events show up in UTC time, so I
>>> have appointments showing up at eg. 1am.
>>>
>>> When I go to Edit, Preferences, Calendar and Task, General, under
>>> timezone it says:
>>>
>>> [x] Use system time (UTC)
>>
>> Could you figure out how Evolution determines what the current time zone
>> is?
>>
>> Guix provides /etc/localtime, which is what libc functions use, but I’m
>> guessing Evolution uses a custom framework, possibly involving a
>> hard-to-believe network of D-Bus services.
>
> I just looked through the source code, and learned that it really,
> really wants “/etc/localtime” to be a symlink, because it wants to
> resolve which timezone alias the user is using, not just the data. If
> it is not a symlink, it runs through a bunch of system specific checks
> (looking up configuration files, etc.) and then tries to compare inodes
> and finally file contents. I get why it wants the name and not just the
> data, but I’m not sure why it tries to figure out the absolute canonical
> source file for the timezone data instead of just taking the data from
> “/etc/localtime”.
>
> It’s easy to patch “evolution-data-server”, but maybe we could do
> better? It seems the “right” way to do what they are doing is to check
> the “TZ” environment variable. However, we don’t set that anymore
> because it causes problems with setuid programs
> (cf. <https://bugs.gnu.org/29212>). We have a comment that says that
> “TZ” is unnecessary, but it actually has a bit more information than
> just having data in “/etc/localtime”, since it could be the name of a
> timezone alias. A small improvement might be to make “/etc/localtime” a
> symlink, but that might run into the same issues described the bug.
Okay, so it turns I don’t know what “TZ” is! :p
It does not contain the timezone name, like “America/New_York”, but
rather its designation, like “EST”. What “evolution-data-server” wants
is the name.
> I’ve noticed a few other problems with timezones in the GNOME ecosystem,
> which is why I was curious about this. Perhaps they all have a common
> root cause.
>
> I’m happy to patch this as stop-gap measure, but is there some way we
> could “do the right thing” here?
I guess there is no standard way to get the name of the system timezone,
and that is why “evolution-data-server” goes to such great lengths to
figure it out.
Sorry for the noise!
-- Tim
This bug report was last modified 5 years and 13 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.