Evolution calendar gets the timezone wrong

DoneSubmitted by Ben Sturmfels.
Details
6 participants
  • Ben Sturmfels
  • Danny Milosavljevic
  • Ben Sturmfels via web
  • Ludovic Courtès
  • Timothy Sample
  • sirmacik
Owner
unassigned
Severity
normal
B
B
Ben Sturmfels wrote on 15 May 2019 15:16
(address . bug-guix@gnu.org)
8736lfrh6y.fsf@sturm.com.au
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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEPn825zvdanEG+SAhAjwF4snAaPAFAlzcETUACgkQAjwF4snA
aPDUXg//WvINtBBTmBXAoEuz+GDrdsqxqaX7U4BZZLL+7zG2gsc3dP5eg4tLQJjn
G5+glJB59mJmsHcDchJccnG3lP6Uvooxxpk5lnhPqJpE+Ivymj0lz0mt8zpW8VjD
nFWlmJeh4275ZQr5Tm89es5/X3K66slBiE65w1dB+2W3+IqNyPUOIl5YrDByZhSj
XQ2VhCNc3P0UrFirLyQHagF1zYEZrxTf5VUkpGTP8TeQomJfnawBWNLOceHsdVQy
M32T2SO13uB+sgVd2504QWbsharFDZwdGqpaMUJhe2UTa+3mXICigg2LNbsaqOPu
0Tch7r/1AGALoDpaqmYdm0d41DMa3WfjAkeX0FWcnI5SVpomn35CpELfsoQQZlHV
x05HzmbkF6CUQCckGlkyOCxxM+2woXx64Dkoe4taqwRDfM3zkkao6xnPKAE3sIIb
AkMakE3iinZ6MBqy449zNgRhGBas+kMBUl6uPiyy01hdvLJEtDifINWopFPTuwVX
gyfndGAO8AqAGqTVhSdZbqy9Vu5Om2+Ond9oNRTVl96o14npZ9q9DJ7kwyfq3qpz
MQYUGWb2zZID3gNIQL9+Zj9JdBfVWvrsqCvhO1/WcG7+RGnBOTJC4VNBpXDgoKJb
JCx+As+9oOEC9bkn4IqJOySep/XZOco/OcPHEvwNEa1FFX8DsiA=
=5E04
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 16 May 2019 13:13
(name . Ben Sturmfels)(address . ben@sturm.com.au)(address . 35746@debbugs.gnu.org)
87y336hct1.fsf@gnu.org
Hi Ben,

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

Toggle quote (8 lines)
> 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.

Thanks,
Ludo’.
B
B
Ben Sturmfels wrote on 16 May 2019 14:57
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 35746@debbugs.gnu.org)
87v9yasgkd.fsf@sturm.com.au
Hi Ludo,

On Thu, 16 May 2019, Ludovic Courtès wrote:
Toggle quote (17 lines)
> Ben Sturmfels <ben@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.

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:

Toggle quote (1 lines)
> new Date().getTimezoneOffset()
0

Where node does this - which is correct:

Toggle quote (1 lines)
> new Date().getTimezoneOffset()
-600

Cheers,
Ben
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEPn825zvdanEG+SAhAjwF4snAaPAFAlzdXiIACgkQAjwF4snA
aPCKLg//XQ1Z0sd4T8KRg4KQezGR9WSST8pwMgpPcPURFvE9OgQbByPlTkXPzXBE
bUkmKKiyfg9y9yASI+pc62+Z6ErxfaztZH7HMgHq7qiN7lvZFuS3ByL1CiS9HB13
WX9DpGvmOXXv6YSodpNywewz4PGRl2sXNM1/On/36ZnLWrH9YRBhcP0eXYmSflKI
8x7iBQyNv8PLuFGnR+pAKrnJSh+LmPmZOH6WTAyjtGHOlvQ6vTRKxXIsS5M6Xjaf
bHknzWqN0nAO+qylN1pVlY2C510ITeysQD4rM/5U01p6DM/73Hjpk6imw0pYhQo8
do8Z5M547VjeXGNufUcNZnzEZseaL65swErALpRBNLWaQ/dP0Nuk+B7wTVWYaNzG
ViqAEncySCw5hHqYFB8bNwGuFFZLx3oNmUwXrEmLiyMFHtFFNY3X+IXUDXrJ90Dk
kvQhxhta2AOL1ZbZtIOnMKtwMV9T97XurtyE2XYA0Ul46NsSkRYdCTAHaMKPRXps
dDVQSNRFEHqJyv+ICF0FcQqFBEQSnvUUe1qlq5PLqBeYfyhS1dWS9nUPY+Jikeop
jZF40CMiGun7FaJivZLLzWaYLgi7gmOyYx7sJsk0dXTDJZq5vieM17A10y2VsTbm
Dc789H4c8Dndkuk8q591nXErTsgsIyHX3WGp4z25SkvHemOzR0k=
=29Z7
-----END PGP SIGNATURE-----

B
B
Ben Sturmfels wrote on 16 May 2019 15:18
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 35746@debbugs.gnu.org)
87h89upmf6.fsf@sturm.com.au
On Thu, 16 May 2019, Ben Sturmfels wrote:

Toggle quote (4 lines)
> 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?

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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEPn825zvdanEG+SAhAjwF4snAaPAFAlzdYz0ACgkQAjwF4snA
aPBMTRAAgfmwZTRa/mn1opK83tfK0XBkliKrEVPg8h+D8W2y+D5n/m/dYCjDlRhl
OrEVd9LLM+e/FfWmwrUQYRooOB3TdvKJTeiakSzvcSRD4MEak92oSP6t/1Pe/dPq
OIruM838qCSzXYOxSD3ZZV9srNxOXLBfNUWI33d27CSBCiTcKr2eVLphw481pBgc
o2rYtfwKN/LU0Hbjv7xYsF94a4cz8p3IxRcBmHWTa2Hdi7Zsdnxi+A1KFRSMzhBL
P60aDxTabn032IZyb1l+wIGWz2u00k3RQHqFrCdoMH1yD/7N35V+14Mdv6y0m42o
e2MmLIEQr/hY9/JyvRSTMzCwLK41PcT1+q67q3q5e6MrgMqOUyn+9ob6d9rNoHAs
e8+K0eKaMhLQ7wnqLpeLiHu88ZAj7fuKRSLtemxWdoNZhH5Q26J/3enjLIOFuOaf
1QUfLGxX+MCCq5n2DyCvV9THMisg6fzK4D5BV0rkuNKJziqn6eefg3nFVjf5pKzy
lH1F7MQyycLQQU1XJ3qO4tevtnf3gJ51N9Tds28airg31XEVsfKHK0PIfzb/jx4d
O6pRBh7tuygLItqYN8dxXznySVPG8anthihW0AqDnmdHS4pAlZbdzc+TDgwoPjt7
yQj69Km1kGLkR556IirkxVfjYreqqB+KNWXA80OTMBS+cee59Zc=
=7jXe
-----END PGP SIGNATURE-----

B
B
Ben Sturmfels wrote on 16 May 2019 15:23
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 35746@debbugs.gnu.org)
87ftpepm7f.fsf@sturm.com.au
On Thu, 16 May 2019, Ben Sturmfels wrote:

Toggle quote (11 lines)
> Possibly completely unrelated, but noting that both icecat and chromium
> do this - which is wrong:
>
>> new Date().getTimezoneOffset()
> 0
>
> Where node does this - which is correct:
>
>> new Date().getTimezoneOffset()
> -600

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

Ben
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEPn825zvdanEG+SAhAjwF4snAaPAFAlzdZFQACgkQAjwF4snA
aPAItg//VmQ6vWQuzg3v6bDA29BN1xQu5kPddTDN6ltowaxHQEvOfsFFEwNNR2bh
y9a4VVoGu48sBOm3f48scjMMG2+WuW/B5mO9mN+/CgElRCfIvx2p/7YjgDKLHmYO
pmPwmgVSX7gUM3TB2fxypmnIp0L+QrFA1F8D3o+k/WX7hPKhziuX1PnkflzwJlZx
JIOSXSW+tTfyNyXvZ3/ANJLOSbAdMmmZ0pGKIg+3R2o0R8xBlUOTrsbYQ6ZL2Ef4
2zU7+8IvgtBvDhfvlMzmUp03lnzpQBzIQY2ytu0jBs1exfVSqiATlL+YmF+Fivn/
HFjcfIEjIFdbgxpmqA3zXqA5iNg/IZuqvNtgAc164cmEr0TM46KgRbMqZU58tjgN
YYbgfIo5agzJ1du8l+1Bs5YDJu6KjV1y+J1KGPEgBvkjP2IvRhz0NnZPI84zFEG/
nyucxLV3AP4RKV33hCM4hFKAxqM5pUJHrMyt7ovlr9HGvVM94Bk3Iih1EIrO674U
UxKKO765HV7K7iuxyRvtRgepoH3FA9dKAk65vdxlHMuriGhoVVu8N2eSWOJ8asUZ
JqVfO0ZMK7hBbNXfo1qp8Z5/Pq78AxsdHvAeZwAIcYkHLR8VGDAZj6JqLpw2+Hho
xF503h8tDGoQucVTmI3EhTak76nfVXq3UOYUvJD3PBsBfW+Hsnc=
=Cxtf
-----END PGP SIGNATURE-----

D
D
Danny Milosavljevic wrote on 16 May 2019 19:18
(name . Ben Sturmfels)(address . ben@sturm.com.au)
20190516191837.77614f92@scratchpost.org
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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlzdm20ACgkQ5xo1VCww
uqWllgf/QW1XCNrNwXnozRVr+1jCbwxXpxnOXHmNpz3aHovdr1oZFl8DD970Jv2X
3lWKCCrIJHqfERqZC0a/HnGSPZMe6cyAltptWV1pXlN9jzhhLTWzekxvotOEb1QY
tSaVlLs/XD9PSztBJxIrhwDcpktZ8cRgsUUSD8c9EJ7BmyiVrrN7/qIJs+pvMMxI
XY3UFtZ9F9uM6PRJJd1hHFrnXFsrLcJJurjh+3psjWFK3xO+OzswSovvHmGC031u
goPxWqx7iyIvVaphZ2v35vGOe8YNVEt7Em/1Vbo7NEqZElubJdnlhqmWB3T+CvHc
haFLfKWjo7dphPyOMxqOAyDgecow/g==
=FBrc
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 17 May 2019 11:02
IceCat/Chromium timezone is wrong
(name . Ben Sturmfels)(address . ben@sturm.com.au)(address . 35746@debbugs.gnu.org)
87d0khzc6f.fsf_-_@gnu.org
Hi Ben,

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

Toggle quote (11 lines)
> Possibly completely unrelated, but noting that both icecat and chromium
> do this - which is wrong:
>
>> new Date().getTimezoneOffset()
> 0
>
> Where node does this - which is correct:
>
>> new Date().getTimezoneOffset()
> -600

I noticed it in IceCat and thought it might be a privacy feature.
But maybe it’s a genuine bug?

Ludo’.
T
T
Timothy Sample wrote on 18 May 2019 19:21
Re: bug#35746: Evolution calendar gets the timezone wrong
(name . Ludovic Courtès)(address . ludo@gnu.org)
87blzzk79x.fsf@ngyro.com
Hello,

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

Toggle quote (19 lines)
> Hi Ben,
>
> Ben Sturmfels <ben@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.

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
L
L
Ludovic Courtès wrote on 18 May 2019 19:51
(name . Ben Sturmfels)(address . ben@sturm.com.au)(address . 35746@debbugs.gnu.org)
874l5rvefo.fsf@gnu.org
Hi Ben,

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

Toggle quote (6 lines)
> 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.

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’.
T
T
Timothy Sample wrote on 18 May 2019 20:43
(name . Ludovic Courtès)(address . ludo@gnu.org)
874l5rk3gx.fsf@ngyro.com
Hi again,

Timothy Sample <samplet@ngyro.com> writes:

Toggle quote (43 lines)
> Hello,
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi Ben,
>>
>> Ben Sturmfels <ben@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.

Toggle quote (7 lines)
> 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
S
S
sirmacik wrote on 19 May 2019 23:17
(address . 35746@debbugs.gnu.org)
20190519211729.GA1798@mail.freearts.agency
Timothy Sample dixit (2019-05-18, 14:43):

Toggle quote (70 lines)
> Hi again,
>
> Timothy Sample <samplet@ngyro.com> writes:
>
> > Hello,
> >
> > Ludovic Courtès <ludo@gnu.org> writes:
> >
> >> Hi Ben,
> >>
> >> Ben Sturmfels <ben@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
>

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
L
L
Ludovic Courtès wrote on 12 Sep 2019 12:00
(name . Ben Sturmfels)(address . ben@sturm.com.au)(address . 35746@debbugs.gnu.org)
87sgp1q1f2.fsf@gnu.org
Hello Ben,

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

Toggle quote (20 lines)
> Ben Sturmfels <ben@sturm.com.au> skribis:
>
>> 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.
>
> 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. :-)

Did you have a chance to look into it?

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 12 Sep 2019 12:05
(name . sirmacik)(address . sirmacik@wioo.waw.pl)
87k1adq17c.fsf@gnu.org
Hello,

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

Toggle quote (4 lines)
> 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.

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’.
B
B
Ben Sturmfels wrote on 12 Sep 2019 15:45
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 35746@debbugs.gnu.org)
87impx4oik.fsf@sturm.com.au
On Thu, 12 Sep 2019, Ludovic Courtès wrote:

Toggle quote (24 lines)
> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> Ben Sturmfels <ben@sturm.com.au> skribis:
>>
>>> 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.
>>
>> 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. :-)
>
> Did you have a chance to look into it?

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

Regards,
Ben
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEPn825zvdanEG+SAhAjwF4snAaPAFAl16S+MACgkQAjwF4snA
aPD2LA//YOczz6lw2onP0opLEm+qKlTdDFBhcCPusmX35e8T3/qI54PwA6e8w/36
43XV4uMXE5HRL6oV5xoaf3EgJMj194/ve9vzrbW6pppGr3ax6X0NHTgxLA0an7qg
V+Onrv90h8JoE6m6jHS5R+KX54VtQOSUFDi701adou7VOmShHNA8lLwjmORioGuD
HlCE+PB6pP93iI2rISLGB324RtNaeQyfcEb2BqcH6w8TKTIxasIaeU3m2dzSLZi6
TpwlCTQrL437xu1ylYwPnd5rlciitWLj9HjOwDmpNE91W17stdtfuIlVTX8r//9y
aJ59nQLunHajf7wfq9NAdFPcW80XhJTzgdOBnmGHX0DRCaK0/WRre1SSLxtP6IIj
j7wpUAIo2ZZOFaXSGWhLu5/7gImXnz6OQ50j4KQ9mXcEWjbAEUTa6ckkQdXLKvGy
MPnacVqjaNG/yU/9QUlSD6UFxI474T4HaVBx/O64KqKiIBfHb4WTy37E+6BHfs/d
iQdOUwke2wT1ne/+sD9PXfjuY2khjexImVZnbqWjHn8dSyNTyGscPo4oppUEPM8M
p+wF9pOFA213FuZzAe+zdKOGwqMjXwRrEHmqfPY9BzrMS0zcAsYengiP9GaUPGZM
aYT5ijCzQnMmJR7JgXIo1V01Silx6FhkOA7ZGTPG/5PrE7buPHw=
=DUrV
-----END PGP SIGNATURE-----

B
B
Ben Sturmfels wrote on 6 Feb 2020 12:27
(name . Ludovic Courtès)(address . ludo@gnu.org)
871rr8hs6x.fsf@sturm.com.au
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:
Toggle quote (13 lines)
> sirmacik <sirmacik@wioo.waw.pl> skribis:
>
>> 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.
>
> 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?

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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEPn825zvdanEG+SAhAjwF4snAaPAFAl47+AcACgkQAjwF4snA
aPA3ABAAq8oyRcjwZHBkMOp90KJCpDMKKC180VKvaa67i+PpOH52u1Z1WaoK/zlW
BXGSb3fG72BTyA2BSkCsc/Tuu3fwoORxSaEA5GiEAjDOqXy0TWfvRrwynzSHTOo+
rbsvcHp5dQkQT7Pv4qCzaHhUd92OELkRLUbF7GXZAMTQ7BCBWoIND0TcjMFkUftJ
GBzHxwHxxkRr5aCjt6UgjF4wJD0Vnee3sKTKDa6KPheYlRPFiMb5LFL4igWY3oa6
fJrCrM6x/w19kODRw+RA99ztbTmkS2daSvF7Fc0JjpHEPJ8fqsBy8khb9LDbZv+X
Zxq4w6gFwlA/P+fsIMRJgTVkvAWX1TZxaFpEgz8K8FEr++SLZCv/gM1VZ7s7icbX
AlS1PyZLjJQh0HfFxaOvRRcbf9YQgg07xe4VByvBiSRNymnaHAg7tRGYs1YALN5j
CeF6wCsfx0nuAxKSYtxJDDt/epXuGUcPudEeKIBbXPNmxRJWO0uIjDtycpjw2nfj
Om7ExImW1AHiiP5VXRN6a3ag3y4+7Z10lIEZpKMr91SahO1cxz7/PXaRoJF/6lzA
Yu5cORZ8xOM+eyPZ1w+M4lMMt+efPv0X6ZdGt9akw6HXk3CWD29q1DGGaZWoSsrm
rBRSLu8Pk/32sFNa0tvRPA6i9QQ56nO3ojttHZ5WHqMU3khneHo=
=Fbry
-----END PGP SIGNATURE-----

Closed
B
B
Ben Sturmfels wrote on 22 Apr 2020 15:38
control message for bug #35746
(address . control@debbugs.gnu.org)
9a8094fd783060df@localhost
unarchive 35746
quit
B
B
Ben Sturmfels wrote on 22 Apr 2020 15:43
Re: bug#35746: IceCat/Chromium timezone is wrong
(address . 35746@debbugs.gnu.org)
87zhb3bppd.fsf@sturm.com.au
On Fri, 17 May 2019, Ludovic Courtès wrote:

Toggle quote (20 lines)
> Hi Ben,
>
> Ben Sturmfels <ben@sturm.com.au> skribis:
>
>> Possibly completely unrelated, but noting that both icecat and chromium
>> do this - which is wrong:
>>
>>> new Date().getTimezoneOffset()
>> 0
>>
>> Where node does this - which is correct:
>>
>>> new Date().getTimezoneOffset()
>> -600
>
> I noticed it in IceCat and thought it might be a privacy feature.
> But maybe it’s a genuine bug?
>
> Ludo’.

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
B
B
Ben Sturmfels wrote on 22 Apr 2020 15:02
Re: IceCat/Chromium timezone is wrong
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 35746@debbugs.gnu.org)
1587560524.2061.1@sturm.com.au
On Fri, May 17, 2019 at 11:02, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (21 lines)
> Hi Ben,
>
> Ben Sturmfels <ben@sturm.com.au> skribis:
>
>> Possibly completely unrelated, but noting that both icecat and
>> chromium
>> do this - which is wrong:
>>
>>> new Date().getTimezoneOffset()
>> 0
>>
>> Where node does this - which is correct:
>>
>>> new Date().getTimezoneOffset()
>> -600
>
> I noticed it in IceCat and thought it might be a privacy feature.
> But maybe it’s a genuine bug?
>
> Ludo’.

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
L
L
Ludovic Courtès wrote on 22 Apr 2020 17:13
Re: bug#35746: IceCat/Chromium timezone is wrong
(name . Ben Sturmfels)(address . ben@sturm.com.au)(address . 35746@debbugs.gnu.org)
87imhrwo3k.fsf@gnu.org
Hi Ben,

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

Toggle quote (2 lines)
> 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.

Indeed. It would be nice if there was a setting specifically for the
timezone rather than the catch-all ‘resistFingerprinting’.

Ludo’.
B
B
Ben Sturmfels via web wrote on 5 May 2020 07:01
(no subject)
(address . 35746@debbugs.gnu.org)
7f41efc768a0.1db588e0a645146d@guile.gnu.org
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
?
Your comment

This issue is archived.

To comment on this conversation send email to 35746@debbugs.gnu.org