bug#35746: Evolution calendar gets the timezone wrong

[Timothy Sample]

Hello,

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
“/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.

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