tzupdate: timezone is not available on your operating system

[DavHau]

Describe the bug
When I use tzupdate to update my time zone, it will always throws and error like this:

Traceback (most recent call last):
  File "/nix/store/5gzd9y9i5kd3y7g1l0m4addf7zmkzjqr-tzupdate-2.0.0/bin/.tzupdate-wrapped", line 9, in <module>
    sys.exit(main())
  File "/nix/store/5gzd9y9i5kd3y7g1l0m4addf7zmkzjqr-tzupdate-2.0.0/lib/python3.8/site-packages/tzupdate.py", line 289, in main
    link_localtime(timezone, args.zoneinfo_path, args.localtime_path)
  File "/nix/store/5gzd9y9i5kd3y7g1l0m4addf7zmkzjqr-tzupdate-2.0.0/lib/python3.8/site-packages/tzupdate.py", line 170, in link_localtime
    raise TimezoneNotLocallyAvailableError(
tzupdate.TimezoneNotLocallyAvailableError: Timezone "Europe/Berlin" requested, but this timezone is not available on your operating system.

Notify maintainers

@michaelpj

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.122, NixOS, 20.09.4331.686720050c3 (Nightingale)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4pre20210519_af4ff64`
 - channels(root): `"home-manager-20.09, nixos-20.09.4331.686720050c3, nixos-20.03-20.03.3328.6d1a044fc9f, nixos-hardware, unstable-21.11pre295280.fa0326ce523"`
 - channels(grmpf): `"nixos-19.09-19.09.2522.75f4ba05c63, nixos-20.03-20.03.3101.0d0660fde3b, nixos-20.09-20.09beta992.7badbf18c45"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:

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

[Artturin]

enable https://search.nixos.org/options?channel=unstable&show=services.tzupdate.enable&from=0&size=50&sort=relevance&query=tzupdate
and run
sudo systemctl start tzupdate

[DavHau]

Thanks, I didn't know about the service. Honestly I think this is not a good user experience.
The service is basically just a wrapper to make the package work under nixos.
It would be better if the package would just work under nixos by default.
The package could be patched/wrapped directly and the service wouldn't be needed anymore, reducing potential confusion.

[Artturin]

sure but people would be confused about why it doesn't work and probably reports "permission denied" because they have time.timeZone set

    # We need to have imperative time zone management for this to work.
    # This will give users an error if they have set an explicit time
    # zone, which is better than silently overriding it.
    time.timeZone = null;

[stale]

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

[sellout]

To make it a bit more ergonomic, my config looks like

environment.shellAliases.tzupdate = "systemctl start tzupdate";
services.tzupdate.enable = true;

So running tzupdate at the command line has the intended effect (despite the indirection through the one-shot service).

But I don’t know why services.tzupdate is better than having a programs.tzupdate that does something like

environment.shellAliases.tzupdate = "timedatectl set-timezone $(${lib.getExe pkgs.tzupdate} --print-only)";
time.timeZone = null;

(/cc @doronbehar)

[doronbehar]

But I don’t know why services.tzupdate is better than having a programs.tzupdate

I also have a systemd timer:

    systemd.timers.tzupdate = {
      timerConfig = {
        OnStartupSec = "30s";
        OnCalendar = "hourly";
        Persistent = true;
      };
      wantedBy = [ "timers.target" ];
    };

[sellout]

I also have a systemd timer:

Ah, that is a great reason!

It would be nice to have the timer as part of the module. E.g., services.tzupdate.interval and if it’s not null, create the timer.

[doronbehar]

I was thinking about it, but I thought I was the only one using this service, because it seems it was broken for a while and no body noticed (see #343748), so I wasn't sure I'll get approvals from others. Also, I'm not sure that there is enough meat for the module to wrap - the timer's configuration is pretty trivial once you have the Systemd service setup.

I think I'll close this 3 years old issue, as the OP seem to got satisfied, and even you got convinced that the Systemd service's existence is justified.

[sellout]

I was thinking about it, but I thought I was the only one using this service, because it seems it was broken for a while and no body noticed (see #343748).

It may have gained some popularity since October as a workaround for the venerable #68489. At least that’s how I discovered it.