nixos/tzupdate: make enabled module actually be enabled

[yajo]

Without this fix, when setting services.tzupdate.enable = true, the service would never run automatically.

Now, it's actually enabled in systemd and it actually gets executed.

Still, it could be improved with a timer as explained in #127984 (comment), but this makes it at least work out of the box when rebooting the system.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[github-actions]

Eval summary

• Added packages: 0
• Removed packages: 0
• Changed packages: 2
• Rebuild Linux: 2
• Rebuild Darwin: 0

[citriqa]

The first commit's commit message is outdated with the addition of the second one, maybe that can be updated.

[citriqa]

Generally, when making changes such as this you will want to rebase and alter existing commits instead of adding another commit, as this keeps the commit history of the project clean once merged and makes it much easier for everyone else to work with after the fact. Rebasing will also allow you to change commit messages in addition to the commit contents. Specifically, you will want to look up how to do interactive rebasing using Git.
In the context of a pull request to a collaborative open source project, the commit history is part of your contribution and functions as documentation, meaning it should receive the same level of care as the code itself instead of reflecting the history of how you arrived at the final set of changes contained within the PR.

[yajo]

I maintain other open source projects. Over time I've noticed it takes more time to explain rebases than to click the merge and squash button that github offers, mostly if there's just one meaningful change to record in history. It also makes contribution experience more pleasant because there are less details to care about.

I respect the decision here nevertheless and will rebase.