[Nix-dev] should libc depend on tzdata

Mihaly Barasz klao at nilcons.com
Tue Apr 29 16:50:48 CEST 2014


My build have just finished and it seems to work fine:

[nix64 at nixos64:~/src/nixpkgs]$ unset TZDIR
[nix64 at nixos64:~/src/nixpkgs]$ TZ=America/New_York ./result/bin/date
Tue Apr 29 10:32:20 EDT 2014
[nix64 at nixos64:~/src/nixpkgs]$ TZ=America/New_York date
Tue Apr 29 14:32:27 America 2014

You can see that the `date` from freshly built coreutils display the
correct behavior, while the normal `date` falls back to GMT.

I've sent a small pull request with the proposed change:
https://github.com/NixOS/nixpkgs/pull/2447
Maybe it's too simplistic and the tzdata dependency should be ignorable?..

Mihaly

On Tue, Apr 29, 2014 at 3:25 PM, Mihaly Barasz <klao at nilcons.com> wrote:
> Hello,
>
> Lately I've been paying more attention to the time zone handling in
> Nix and I realized something that strikes me as weird. I've been
> bumping into this before, but didn't pay much attention. The issue is
> the following:
>
> To get proper time zone handling in Nix/NixOS you _have to_ have the
> TZDIR environment variable set.
>
> This is in stark contrast with "traditional" linux distributions,
> where libc has the location of "system time zone database" compiled
> in, and you only need to set TZDIR if you want to use a different one.
>
> And, this does cause random issues once in a while: eg., the
> environment variable is not set by cron on NixOS, so stuff isn't
> working from cron if you change your TZ...
>
> This also seems contrary to Nix' spirit that the dependencies should
> be explicit... So, I'd like to raise the following question:
>
> Shouldn't libc depend explicitly on tzdata and use it as its `zonedir`?
>
> This might turn out not completely trivial technically, I didn't
> finish testing it yet. But, I didn't get into roadblocks yet. And, if
> this is done, there are potential simplification opportunities; most
> importantly: we don't need to set up TZDIR in all the random places.
> :)
>
> Opinions?
>
> Mihaly


More information about the nix-dev mailing list