glibc looking for zoneinfo files in the wrong place; failing silently

[cdyson37]

When calling e.g. localtime, glibc looks zoneinfo files in its own derivation, and not in tzdata. Missing timezones are silently ignored (I believe this bit is not nixpkgs-specific), so in the example below, the output is off by one hour.

To Reproduce

$ cat localtime.c 
#include <time.h>
#include <stdio.h>

int main ()
{
  /* Fri 26 Jul 12:53:20 UTC 2019 */
  time_t t = 1564145600;
  struct tm *result = localtime (&t);
  if (result == NULL)
  {
    puts ("Error");
    return 1;
  }
  puts (asctime (result));

  return 0;
}

$ nix-shell -p gcc --run "gcc localtime.c -o localtime" && TZ=Europe/London ./localtime
Fri Jul 26 12:53:20 2019

strace shows its looking in the glibc derivation for zoneinfo, but actually the zoneinfo files are stored elsewhere.

$ TZ=Europe/London strace ./localtime |& grep London
openat(AT_FDCWD, "/nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/share/zoneinfo/Europe/London", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Expected behavior
On Centos 7 (correct output)

$ gcc localtime.c -o localtime && TZ=Europe/London ./localtime
Fri Jul 26 13:53:20 2019

Metadata

• system: "x86_64-linux"
• host os: Linux 3.10.0-957.12.1.el7.x86_64, CentOS Linux, 7 (Core)
• multi-user?: no
• sandbox: no
• version: nix-env (Nix) 2.2.2
• channels(dyson): "nixpkgs-19.03.172807.b2ec3b6db2b, nixos-19.03-19.03"
• nixpkgs: /home/dyson/.nix-defexpr/channels/nixpkgs

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: glibc
# a list of nixos modules affected by the problem
module:

[matthewbauer]

I get this on my NixOS machine:

openat(AT_FDCWD, "/etc/zoneinfo/Europe/London", O_RDONLY|O_CLOEXEC) = 3

But this is probably because TZDIR=/etc/zoneinfo. Does /etc/zoneinfo or /usr/share/zoneinfo exist on CentOS?

[cdyson37]

/usr/share/zoneinfo does exist on CentOS and setting TZDIR to point to that does fix the problem - thanks!

But I prefer not to rely on impure environment variables to get the correct behaviour, so for the time being I will probably overlay glibc to get consistency.

[stale]

I marked this as stale due to inactivity. → More info