nixos/nix-{gc,optimise}: make dates parameter more consistent

[SFrijters]

Kind of a followup to #362366

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.

[SuperSandro2000]

I don't think we want a potentially nested list here

[SuperSandro2000]

Maybe check if it is a string and then put it into a list so we always have a list?

[SFrijters]

Yeah, I was wondering if that was necessary - I took this from the original nix-optimise but it looked weird to me.

[SuperSandro2000]

We probably should adapt the description to mention that it can be a list

[SFrijters]

I've slightly changed the description attribute for both; the type is also displayed directly on the options pages so that should be clear enough in combination?

[llakala]

I'll link #345573 here. It'd be nice to eventually standardize on one representation for dates.

[SFrijters]

Ah, I didn't even know about that issue. If we can decide on the "correct" way I don't mind extending this PR to include autoUpgrade.

In my implementation I chose to make gc/optimise more relaxed about their inputs rather than deprecate something. Personally I am content if I can at least use a consistent format in my config, I don't mind which one it is.

[llakala]

There are many other modules than the specific three mentioned there that could do with being standardized. I just set up this search, using regex to avoid instances of systemd.timers or systemd.timedated. I'm sure it's not perfect, but it paints a strong enough picture. The types I saw used most often after scrolling through:

• str (the most common by far)
• singleLineStr
• listOf str
• either str (listOf str (allowing both)
• unitOption (seen here. Intruiging, but a bit overly-verbose in my opinion.

Of these, I'd say the main three options are str, listOf str, and either (allowing both).

I personally think lists are the most clear when it comes to signaling to the user that multiple dates are accepted, but it would be a breaking change for many modules. Most people will also only put in one date, so they would end up constantly having to go through the inconvenience of a wrapping list.

If we decided not to go with listOf str, I think str would be my second choice. While I'm annoyed by the expected comma separator, I find either too ambiguous. People don't expect a list to take multiple types, and won't realize it unless they actually check the source code.

Final note - if we were to make a treewide change, I'd like to actually make a dates type in lib.types, and then just have all the modules use that as their type. This would set things up for the future well. Some documentation would also be nice. I realize I'm putting a lot on your plate for a PR that started out small - so I'm happy to collaborate with you on setting these things up if you're interested.

[SFrijters]

To be honest, I was looking to scale back my nixpkgs time a bit this year and I just wanted to fix some personal annoyances. I don't think I'm the right person to spearhead this PR if the scope blows up so much.

[llakala]

Totally fine! I can make a future PR, then. I'll put my vote in for standardizing on a string. It breaks the least people's workflows, and matches the systemd standard.