libexpr: Canonicalize TOML timestamps for toml11 > 4.0

[xokdvium]

Motivation

This addresses several changes from toml11 4.0 bump in
nixpkgs 1.

1. Added more regression tests for timestamp formats.
   Special attention needs to be paid to the precision
   of the subsecond range for local-time. Prior versions select the closest
   (upwards) multiple of 3 with a hard cap of 9 digits.

2. Normalize local datetime and offset datetime to always
   use the uppercase separator T. This is actually the issue
   surfaced in 2. This canonicalization is basically a requirement
   by (a certain reading) of rfc3339 section 5.6 3.

3. If using toml11 >= 4.0 also keep the old behavior wrt
   to the number of digits used for subsecond part of the local-time.
   Newer versions cap it at 6 digits unconditionally preserve the input.

Context

Fixes #11441

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[xokdvium]

cc @emilazy, @trofi

[emilazy]

My opinion is that this feature is just broken:

nix-repl> :p builtins.fromTOML ''uhh = 1970-01-01''
{
  uhh = {
    _type = "timestamp";
    value = "1970-01-01";
  };
}

nix-repl> :p builtins.fromTOML ''uhh = { _type = "timestamp", value = "1970-01-01" }''
{
  uhh = {
    _type = "timestamp";
    value = "1970-01-01";
  };
}

This is either throwing away information from the TOML document, or, very generously, introducing a Nix‐specific syntactic extension to TOML that allows specifying timestamps as tables in a way that disables all validation for them. No code that consumes a timestamp can assume anything about its value without rejecting valid TOML documents:

nix-repl> :p builtins.fromTOML ''uhh = { _type = "timestamp", value = "oops!" }''      
{
  uhh = {
    _type = "timestamp";
    value = "oops!";
  };
}

Given this issue, the feature’s experimental status, the TOML spec’s refusal to pin down exact semantics for timestamps, and the demonstrated willingness of TOML implementations to change their behaviour, I feel it should be removed until someone can come up with semantics for it that make sense (e.g. annotating every node with a type, rather than just timestamps).

I can understand wanting to decouple that decision from unblocking the toml11 upgrade in Nixpkgs, though. The previous “multiple of three” behaviour and the new behaviour both seem weird. I would probably lean towards the latter, as it reduces code complexity by avoiding going out of the way to keep an experimental feature stable. However it’s clear that there would have to be a lot of consideration towards how to handle eval compatibility for this feature were it ever stabilised.

It’s hard to search for users of a feature like this but the GitHub results for the feature name mostly seem like people going down the list of experimental features and enabling everything that seems like it might be a good idea. I’d guess nobody is relying on it. Maybe time to cut the losses on this one and free up the feature for someone to re‐do properly in the future.

All that said, it seems good to apply a change like this to 2.24 regardless.

[emilazy]

cc @andreabedini – did you end up using this? I see that input-output-hk/foliage#46 is still open. A plugin would be another option in lieu of stable semantics here.

[Mic92]

We can discuss this today.

[Mic92]

From the nix team meeting:

• we will merge this as it for backporting
• then we discuss what we do next

[xokdvium]

This breaks nixpkgs https://github.com/NixOS/nix/actions/runs/16947837644/job/48033191459

[andreabedini]

cc @andreabedini – did you end up using this? I see that input-output-hk/foliage#46 is still open. A plugin would be another option in lieu of stable semantics here.

Sorry for the long radio silence. How would a plugin work? If there a setup I can copy?