Allow TZ to be exported for setting the timezone of a nix-shell.

[jperras]

Feature description

In the shellHook section of a nix-shell derivation, any exports of TZ environment variables are blocked from occurring.

A minimal nix-shell that reproduces the issue:

with import <nixpkgs> {};
stdenv.mkDerivation {
  name = "impurePythonEnv";
  buildInputs = [
    hello
  ]

  src = null;
  shellHook = ''
    export TZ=utc
  '';
}

When inside the environment created by this shell, the date function returns:

[nix-shell:~/src/scratch]$ date
Thu Jan 30 14:39:51 EST 2020

which is in the EST timezone, that of my host.

Target users

My particular use case is, I believe, a common one:

I have a shell.nix that I've created for a project that assumes it will be run on a system whose timezone is set to UTC. My host, however, is not in UTC, because I don't live in that timezone, and don't wish to change the clock on my host to accommodate.

While it would be best to make as much of the codebase as timezone-independent as possible, this is not always possible.

[jperras]

The current workaround that I have come up with is to explicitly export the TZ in the .envrc immediately before the call to eval "$(lorri direnv)".

[curiousleo]

Hi, thanks for the report!

Your example console output shows that nix-shell does not respect TZ. This is due to some hackery in nix-build.cc (which probably has very good reasons - I could trace this behaviour back to https://github.com/NixOS/nix/commit/79dee4283de798da8728dd8504cdc4ab5c9b9fe0, even before nix-build [which also contains the code for nix-shell] was ported to C++!).

Am I understanding it correctly that you would like lorri's behaviour to deviate from nix-shell's in this case?

If so: the combination of

• lorri does what nix-shell does in this case, and
• there is an easy way to achieve the effect you want in a lorri setup (via .envrc)

makes me think that we should not special-case TZ environment variable handling in lorri.

[jperras]

@curiousleo It seems it is twofold, then, because lorri does specifically punt on exporting TZ:

https://github.com/target/lorri/blob/eff0d976d8a2555085fcfa74453419fce5b10434/src/ops/direnv/envrc.bash#L135

However, since nix-shell itself doesn't ever respect the TZ (as you demonstrated, and as I should have realized as well), perhaps the fact that lorri punts on it is moot.

I'm fine with having to utilize .envrc to achieve what I needed, of course. This was more attempting to call out a situation that I'm certain others might have encountered.

[grahamc]

I see lorri as an opportunity to research feature development before they reach Nix.

I think it is generally good that nix-shell and lorri don't change the TZ variable. I agree there are cases where it would be good to specifically instruct nix-shell to override the TZ, too.

Maybe we could do some experiments on ways we could extend lorri (and then nix-shell) to support this. For example, and this is just an example after about 1 minute of thought, having a variable passed to the derivation explicitly instructing Nix to pass them. Like:

pkgs.mkShell {
   ...
  TZ = "Pacific/Pago_Pago";
   propagateToShellEnv = [ "TZ" ];
}

Note that I would want to collaborate with Nix upstream on the design of this interface, because I feel it is important that nix-shell eventually learn the same trick.