From mboxrd@z Thu Jan 1 00:00:00 1970 From: sirmacik Subject: bug#35746: Evolution calendar gets the timezone wrong Date: Sun, 19 May 2019 23:17:29 +0200 Message-ID: <20190519211729.GA1798@mail.freearts.agency> References: <8736lfrh6y.fsf@sturm.com.au> <87y336hct1.fsf@gnu.org> <87blzzk79x.fsf@ngyro.com> <874l5rk3gx.fsf@ngyro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:59796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hSTC7-0004aG-Ey for bug-guix@gnu.org; Sun, 19 May 2019 17:18:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hSTC3-0000FN-8H for bug-guix@gnu.org; Sun, 19 May 2019 17:18:09 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:50335) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hSTBy-000059-4T for bug-guix@gnu.org; Sun, 19 May 2019 17:18:05 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hSTBx-0007Le-UT for bug-guix@gnu.org; Sun, 19 May 2019 17:18:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <874l5rk3gx.fsf@ngyro.com> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: 35746@debbugs.gnu.org Timothy Sample dixit (2019-05-18, 14:43): > Hi again, > > Timothy Sample writes: > > > Hello, > > > > Ludovic Courtès writes: > > > >> Hi Ben, > >> > >> Ben Sturmfels 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. ). 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