all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#35746: Evolution calendar gets the timezone wrong
@ 2019-05-15 13:16 Ben Sturmfels
  2019-05-16 11:13 ` Ludovic Courtès
  2020-05-05  5:01 ` bug#35746: (no subject) Ben Sturmfels via web
  0 siblings, 2 replies; 19+ messages in thread
From: Ben Sturmfels @ 2019-05-15 13:16 UTC (permalink / raw)
  To: 35746

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-05-15 13:16 bug#35746: Evolution calendar gets the timezone wrong Ben Sturmfels
@ 2019-05-16 11:13 ` Ludovic Courtès
  2019-05-16 12:57   ` Ben Sturmfels
  2019-05-18 17:21   ` Timothy Sample
  2020-05-05  5:01 ` bug#35746: (no subject) Ben Sturmfels via web
  1 sibling, 2 replies; 19+ messages in thread
From: Ludovic Courtès @ 2019-05-16 11:13 UTC (permalink / raw)
  To: Ben Sturmfels; +Cc: 35746

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.

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-05-16 11:13 ` Ludovic Courtès
@ 2019-05-16 12:57   ` Ben Sturmfels
  2019-05-16 13:18     ` Ben Sturmfels
                       ` (4 more replies)
  2019-05-18 17:21   ` Timothy Sample
  1 sibling, 5 replies; 19+ messages in thread
From: Ben Sturmfels @ 2019-05-16 12:57 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 35746

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

Hi Ludo,

On Thu, 16 May 2019, Ludovic Courtès wrote:
> 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:

> new Date().getTimezoneOffset()
0

Where node does this - which is correct:

> new Date().getTimezoneOffset()
-600

Cheers,
Ben

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-05-16 12:57   ` Ben Sturmfels
@ 2019-05-16 13:18     ` Ben Sturmfels
  2019-05-16 13:23     ` Ben Sturmfels
                       ` (3 subsequent siblings)
  4 siblings, 0 replies; 19+ messages in thread
From: Ben Sturmfels @ 2019-05-16 13:18 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 35746

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

On Thu, 16 May 2019, Ben Sturmfels wrote:

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-05-16 12:57   ` Ben Sturmfels
  2019-05-16 13:18     ` Ben Sturmfels
@ 2019-05-16 13:23     ` Ben Sturmfels
  2019-05-16 17:18     ` Danny Milosavljevic
                       ` (2 subsequent siblings)
  4 siblings, 0 replies; 19+ messages in thread
From: Ben Sturmfels @ 2019-05-16 13:23 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 35746

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

On Thu, 16 May 2019, Ben Sturmfels wrote:

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-05-16 12:57   ` Ben Sturmfels
  2019-05-16 13:18     ` Ben Sturmfels
  2019-05-16 13:23     ` Ben Sturmfels
@ 2019-05-16 17:18     ` Danny Milosavljevic
  2019-05-17  9:02     ` bug#35746: IceCat/Chromium timezone is wrong Ludovic Courtès
  2019-05-18 17:51     ` bug#35746: Evolution calendar gets the timezone wrong Ludovic Courtès
  4 siblings, 0 replies; 19+ messages in thread
From: Danny Milosavljevic @ 2019-05-16 17:18 UTC (permalink / raw)
  To: Ben Sturmfels; +Cc: 35746

[-- Attachment #1: Type: text/plain, Size: 211 bytes --]

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: IceCat/Chromium timezone is wrong
  2019-05-16 12:57   ` Ben Sturmfels
                       ` (2 preceding siblings ...)
  2019-05-16 17:18     ` Danny Milosavljevic
@ 2019-05-17  9:02     ` Ludovic Courtès
  2020-04-22 13:02       ` Ben Sturmfels
                         ` (2 more replies)
  2019-05-18 17:51     ` bug#35746: Evolution calendar gets the timezone wrong Ludovic Courtès
  4 siblings, 3 replies; 19+ messages in thread
From: Ludovic Courtès @ 2019-05-17  9:02 UTC (permalink / raw)
  To: Ben Sturmfels; +Cc: 35746

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-05-16 11:13 ` Ludovic Courtès
  2019-05-16 12:57   ` Ben Sturmfels
@ 2019-05-18 17:21   ` Timothy Sample
  2019-05-18 18:43     ` Timothy Sample
  1 sibling, 1 reply; 19+ messages in thread
From: Timothy Sample @ 2019-05-18 17:21 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Ben Sturmfels, 35746

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.

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-05-16 12:57   ` Ben Sturmfels
                       ` (3 preceding siblings ...)
  2019-05-17  9:02     ` bug#35746: IceCat/Chromium timezone is wrong Ludovic Courtès
@ 2019-05-18 17:51     ` Ludovic Courtès
  2019-09-12 10:00       ` Ludovic Courtès
  4 siblings, 1 reply; 19+ messages in thread
From: Ludovic Courtès @ 2019-05-18 17:51 UTC (permalink / raw)
  To: Ben Sturmfels; +Cc: 35746

Hi Ben,

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.  :-)

Let me know how it goes!

Ludo’.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-05-18 17:21   ` Timothy Sample
@ 2019-05-18 18:43     ` Timothy Sample
  2019-05-19 21:17       ` sirmacik
  0 siblings, 1 reply; 19+ messages in thread
From: Timothy Sample @ 2019-05-18 18:43 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Ben Sturmfels, 35746

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-05-18 18:43     ` Timothy Sample
@ 2019-05-19 21:17       ` sirmacik
  2019-09-12 10:05         ` Ludovic Courtès
  0 siblings, 1 reply; 19+ messages in thread
From: sirmacik @ 2019-05-19 21:17 UTC (permalink / raw)
  To: 35746

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

> 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-05-18 17:51     ` bug#35746: Evolution calendar gets the timezone wrong Ludovic Courtès
@ 2019-09-12 10:00       ` Ludovic Courtès
  2019-09-12 13:45         ` Ben Sturmfels
  0 siblings, 1 reply; 19+ messages in thread
From: Ludovic Courtès @ 2019-09-12 10:00 UTC (permalink / raw)
  To: Ben Sturmfels; +Cc: 35746

Hello Ben,

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?

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-05-19 21:17       ` sirmacik
@ 2019-09-12 10:05         ` Ludovic Courtès
  2020-02-06 11:27           ` Ben Sturmfels
  0 siblings, 1 reply; 19+ messages in thread
From: Ludovic Courtès @ 2019-09-12 10:05 UTC (permalink / raw)
  To: sirmacik; +Cc: 35746

Hello,

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?

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-09-12 10:00       ` Ludovic Courtès
@ 2019-09-12 13:45         ` Ben Sturmfels
  0 siblings, 0 replies; 19+ messages in thread
From: Ben Sturmfels @ 2019-09-12 13:45 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 35746

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

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

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: Evolution calendar gets the timezone wrong
  2019-09-12 10:05         ` Ludovic Courtès
@ 2020-02-06 11:27           ` Ben Sturmfels
  0 siblings, 0 replies; 19+ messages in thread
From: Ben Sturmfels @ 2020-02-06 11:27 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: sirmacik, 35746-done

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: IceCat/Chromium timezone is wrong
  2019-05-17  9:02     ` bug#35746: IceCat/Chromium timezone is wrong Ludovic Courtès
@ 2020-04-22 13:02       ` Ben Sturmfels
  2020-04-22 13:43       ` Ben Sturmfels
       [not found]       ` <875zdrd4vv.fsf@sturm.com.au>
  2 siblings, 0 replies; 19+ messages in thread
From: Ben Sturmfels @ 2020-04-22 13:02 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 35746



On Fri, May 17, 2019 at 11:02, Ludovic Courtès <ludo@gnu.org> wrote:
> 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:
https://lists.gnu.org/archive/html/bug-gnuzilla/2019-06/msg00010.html

Regards,
Ben


^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: IceCat/Chromium timezone is wrong
  2019-05-17  9:02     ` bug#35746: IceCat/Chromium timezone is wrong Ludovic Courtès
  2020-04-22 13:02       ` Ben Sturmfels
@ 2020-04-22 13:43       ` Ben Sturmfels
       [not found]       ` <875zdrd4vv.fsf@sturm.com.au>
  2 siblings, 0 replies; 19+ messages in thread
From: Ben Sturmfels @ 2020-04-22 13:43 UTC (permalink / raw)
  To: 35746

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

> 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:
https://lists.gnu.org/archive/html/bug-gnuzilla/2019-06/msg00010.html

Regards,
Ben

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: IceCat/Chromium timezone is wrong
       [not found]       ` <875zdrd4vv.fsf@sturm.com.au>
@ 2020-04-22 15:13         ` Ludovic Courtès
  0 siblings, 0 replies; 19+ messages in thread
From: Ludovic Courtès @ 2020-04-22 15:13 UTC (permalink / raw)
  To: Ben Sturmfels; +Cc: 35746

Hi Ben,

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

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#35746: (no subject)
  2019-05-15 13:16 bug#35746: Evolution calendar gets the timezone wrong Ben Sturmfels
  2019-05-16 11:13 ` Ludovic Courtès
@ 2020-05-05  5:01 ` Ben Sturmfels via web
  1 sibling, 0 replies; 19+ messages in thread
From: Ben Sturmfels via web @ 2020-05-05  5:01 UTC (permalink / raw)
  To: 35746

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:
https://lists.gnu.org/archive/html/bug-gnuzilla/2019-06/msg00010.html

Regards,
Ben





^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2020-05-05  5:13 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-05-15 13:16 bug#35746: Evolution calendar gets the timezone wrong Ben Sturmfels
2019-05-16 11:13 ` Ludovic Courtès
2019-05-16 12:57   ` Ben Sturmfels
2019-05-16 13:18     ` Ben Sturmfels
2019-05-16 13:23     ` Ben Sturmfels
2019-05-16 17:18     ` Danny Milosavljevic
2019-05-17  9:02     ` bug#35746: IceCat/Chromium timezone is wrong Ludovic Courtès
2020-04-22 13:02       ` Ben Sturmfels
2020-04-22 13:43       ` Ben Sturmfels
     [not found]       ` <875zdrd4vv.fsf@sturm.com.au>
2020-04-22 15:13         ` Ludovic Courtès
2019-05-18 17:51     ` bug#35746: Evolution calendar gets the timezone wrong Ludovic Courtès
2019-09-12 10:00       ` Ludovic Courtès
2019-09-12 13:45         ` Ben Sturmfels
2019-05-18 17:21   ` Timothy Sample
2019-05-18 18:43     ` Timothy Sample
2019-05-19 21:17       ` sirmacik
2019-09-12 10:05         ` Ludovic Courtès
2020-02-06 11:27           ` Ben Sturmfels
2020-05-05  5:01 ` bug#35746: (no subject) Ben Sturmfels via web

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.