Evolution calendar gets the timezone wrong

Hi Folks,

My Guix System is configured with (timezone "Australia/Melbourne") which

is reflected by the `date` command as well as the Gnome clock.

$ date

Wed May 15 23:03:34 AEST 2019

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)

The timezone can be overridden manually by unchecking the box and selecting at

timezone, which fixes the problem but shouldn't be necessary.

For what it's worth, the Gnome 3 notifications that show when you click on the

Gnome clock are in the correct timezone.

Regards,

Ben

Hi Ben,

Ben Sturmfels <ben@sturm.com.au> skribis:

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.

Thanks,

Ludo’.

Hi Ludo,

On Thu, 16 May 2019, Ludovic Courtès wrote:

One clue is that when I run `evolution` in a terminal it logs the

following error:

(evolution:4359): libecal-CRITICAL **: 17:22:46.073: e_cal_util_get_system_timezone: assertion 'location != NULL' failed

So my C troubleshooting skills are very rusty, but this is a learning

opportunity!

`strace evolution 2>&1 | grep /etc/localtime` indicates /etc/localtime

is being opened at least.

I've downloaded the source with `guix build --source

evolution-data-server`, extracted and found the the function

"e_cal_util_get_system_timezone()" at src/calendar/libecal/e-cal-util.c:1507

which calls down to "system_timezone_find()" in e-cal-system-timezone.c:522

where it looks up the timezone and compares it to a list of valid zones.

So I run `gdb evolution`, but don't seem to have the debugging symbols.

How does one get/build the debugging symbols? Can `guix build` help with

this?

Possibly completely unrelated, but noting that both icecat and chromium

do this - which is wrong:

0

Where node does this - which is correct:

-600

Cheers,

Ben

On Thu, 16 May 2019, Ben Sturmfels wrote:

I mean, I know from long ago university projects that I need "-g -O0".

Does guix have any secret weapons to help with this?

Ben

On Thu, 16 May 2019, Ben Sturmfels wrote:

I also tested epiphany which shows the correct offset of "-600".

Ben

You'd have to add a debug output to the package in question

(outputs '("out" "debug"))

and possibly pass --enable-debug to configure.

Unfortunately, for space reasons, that's not the default in Guix.

Hi Ben,

Ben Sturmfels <ben@sturm.com.au> skribis:

I noticed it in IceCat and thought it might be a privacy feature.

But maybe it’s a genuine bug?

Ludo’.

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

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

Hi Ben,

Ben Sturmfels <ben@sturm.com.au> skribis:

Looking more closely, ‘system_timezone_find’ first tries to see if

/etc/localtime is a symlink and if yes reads its target (but it’s never

a symlink, AFAIK), and later on tries to compare /etc/localtime to files

found under ‘SYSTEM_ZONEINFODIR’.

Problem is:

#define SYSTEM_ZONEINFODIR "/usr/share/zoneinfo"

So probably, if you substitute “/usr/” with the prefix of the ‘tzdata’

package, it’ll work much better. :-)

Let me know how it goes!

Ludo’.

Hi again,

Timothy Sample <samplet@ngyro.com> writes:

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 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

Timothy Sample dixit (2019-05-18, 14:43):

Hey Guix,

This problem seems to be also present also for other programs such as

GNU IceCat which reads UTC timezone every time, despite Europe/Warsaw

being set in my config.scm.

--

sirmacik

PGP: 0xE0DC81D523891771

Hello Ben,

Ludovic Courtès <ludo@gnu.org> skribis:

Did you have a chance to look into it?

Thanks,

Ludo’.

Hello,

sirmacik <sirmacik@wioo.waw.pl> skribis:

I can confirm this (it’s not clear that it relates to the

evolution-data-server issue.)

I vaguely remember that we once had an explanation to the IceCat

timezone issue but I can no longer find it… Does it ring a bell to

anyone reading this?

Thanks,

Ludo’.

On Thu, 12 Sep 2019, Ludovic Courtès wrote:

Sorry Ludo, no, not yet. It's still on my list to take a look at some

time though.

Regards,

Ben

Marius B. advised that the Evolution timezone issue was addressed in

2a80d9e55299214a3f0b4f585767b4c81c9d5c7d. I hadn't noticed, but can

confirm that my times are now showing up perfectly in Evolution and

Gnome Calendar, yay thanks! Epiphany is also showing the correct

timezone now for me with `new Date().getTimezoneOffset()`.

On Thu, 12 Sep 2019, Ludovic Courtès wrote:

IceCat and Chromium are still showing UTC for me, so that issue is

clearly not directly related to the now fixed Evolution issue. Will

close this bug report since it's about Evolution.

Regards,

Ben

unarchive 35746

quit

On Fri, 17 May 2019, Ludovic Courtès wrote:

This does appear to be a privacy feature. To report the correct timezone offset, go to "about:config" and disable "privacy.resistFingerprinting" then restart IceCat.

Note that toggling "privacy.resistFingerprinting" immediately changed the result of `new Date().toString()` on all tabs, but `new Date().getTimezoneOffset()` was changed

only on the about:config tab. After a restart all tabs showed the correct offset.

See this IceCat bug report discussion:

Regards,

Ben

On Fri, May 17, 2019 at 11:02, Ludovic Courtès <ludo@gnu.org> wrote:

This does appear to be a privacy feature. To report the correct

timezone offset, go to "about:config" and disable

"privacy.resistFingerprinting" then restart IceCat.

Note that toggling "privacy.resistFingerprinting" immediately changed

the result of `new Date().toString()` on all tabs, but `new

Date().getTimezoneOffset()` was changed

only on the about:config tab. After a restart all tabs showed the

correct offset.

See this IceCat bug report discussion:

Regards,

Ben

Hi Ben,

Ben Sturmfels <ben@sturm.com.au> skribis:

Indeed. It would be nice if there was a setting specifically for the

timezone rather than the catch-all ‘resistFingerprinting’.

Ludo’.

This does appear to be a privacy feature in IceCat. To report the correct timezone offset, go to about:config" and disable "privacy.resistFingerprinting" then restart IceCat.

Note that toggling "privacy.resistFingerprinting" immediately changed the result of `new ate().toString()` on all tabs, but `new Date().getTimezoneOffset()` was changed only on the about:config tab. After a restart all tabs showed the correct offset.

See this IceCat bug report discussion:

Regards,

Ben