From: Timothy Sample <samplet@ngyro.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Ben Sturmfels <ben@sturm.com.au>, 35746@debbugs.gnu.org
Subject: bug#35746: Evolution calendar gets the timezone wrong
Date: Sat, 18 May 2019 14:43:58 -0400 [thread overview]
Message-ID: <874l5rk3gx.fsf@ngyro.com> (raw)
In-Reply-To: <87blzzk79x.fsf@ngyro.com> (Timothy Sample's message of "Sat, 18 May 2019 13:21:46 -0400")
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
next prev parent reply other threads:[~2019-05-18 18:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874l5rk3gx.fsf@ngyro.com \
--to=samplet@ngyro.com \
--cc=35746@debbugs.gnu.org \
--cc=ben@sturm.com.au \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).