[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#35746: Evolution calendar gets the timezone wrong

From: Timothy Sample
Subject: bug#35746: Evolution calendar gets the timezone wrong
Date: Sat, 18 May 2019 13:21:46 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)


Ludovic Courtès <address@hidden> writes:

> Hi Ben,
> Ben Sturmfels <address@hidden> 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

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.

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?

-- Tim

reply via email to

[Prev in Thread] Current Thread [Next in Thread]