From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timothy Sample Subject: bug#35746: Evolution calendar gets the timezone wrong Date: Sat, 18 May 2019 14:43:58 -0400 Message-ID: <874l5rk3gx.fsf@ngyro.com> References: <8736lfrh6y.fsf@sturm.com.au> <87y336hct1.fsf@gnu.org> <87blzzk79x.fsf@ngyro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:57657) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hS4KN-0000He-CT for bug-guix@gnu.org; Sat, 18 May 2019 14:45:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hS4KM-0000K4-4D for bug-guix@gnu.org; Sat, 18 May 2019 14:45:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:47656) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hS4KL-0000Jr-W2 for bug-guix@gnu.org; Sat, 18 May 2019 14:45:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hS4KL-0001Gp-RH for bug-guix@gnu.org; Sat, 18 May 2019 14:45:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87blzzk79x.fsf@ngyro.com> (Timothy Sample's message of "Sat, 18 May 2019 13:21:46 -0400") 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: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Ben Sturmfels , 35746@debbugs.gnu.org Hi again, Timothy Sample writes: > Hello, > > Ludovic Court=C3=A8s 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=E2= =80=99m >> 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 =E2=80=9C/etc/localtime=E2=80=9D 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=E2=80=99m not sure why it tries to figure out the absolute ca= nonical > source file for the timezone data instead of just taking the data from > =E2=80=9C/etc/localtime=E2=80=9D. > > It=E2=80=99s easy to patch =E2=80=9Cevolution-data-server=E2=80=9D, but m= aybe we could do > better? It seems the =E2=80=9Cright=E2=80=9D way to do what they are doi= ng is to check > the =E2=80=9CTZ=E2=80=9D environment variable. However, we don=E2=80=99t= set that anymore > because it causes problems with setuid programs > (cf. ). We have a comment that says that > =E2=80=9CTZ=E2=80=9D is unnecessary, but it actually has a bit more infor= mation than > just having data in =E2=80=9C/etc/localtime=E2=80=9D, since it could be t= he name of a > timezone alias. A small improvement might be to make =E2=80=9C/etc/local= time=E2=80=9D a > symlink, but that might run into the same issues described the bug. Okay, so it turns I don=E2=80=99t know what =E2=80=9CTZ=E2=80=9D is! :p It does not contain the timezone name, like =E2=80=9CAmerica/New_York=E2=80= =9D, but rather its designation, like =E2=80=9CEST=E2=80=9D. What =E2=80=9Cevolutio= n-data-server=E2=80=9D wants is the name. > I=E2=80=99ve noticed a few other problems with timezones in the GNOME eco= system, > which is why I was curious about this. Perhaps they all have a common > root cause. > > I=E2=80=99m happy to patch this as stop-gap measure, but is there some wa= y we > could =E2=80=9Cdo the right thing=E2=80=9D here? I guess there is no standard way to get the name of the system timezone, and that is why =E2=80=9Cevolution-data-server=E2=80=9D goes to such great = lengths to figure it out. Sorry for the noise! -- Tim