From: sirmacik <sirmacik@wioo.waw.pl>
To: 35746@debbugs.gnu.org
Subject: bug#35746: Evolution calendar gets the timezone wrong
Date: Sun, 19 May 2019 23:17:29 +0200 [thread overview]
Message-ID: <20190519211729.GA1798@mail.freearts.agency> (raw)
In-Reply-To: <874l5rk3gx.fsf@ngyro.com>
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
next prev parent reply other threads:[~2019-05-19 21:18 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
2019-05-19 21:17 ` sirmacik [this message]
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=20190519211729.GA1798@mail.freearts.agency \
--to=sirmacik@wioo.waw.pl \
--cc=35746@debbugs.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).