| 12 Aug 2025 |
 emily | fyi parse-toml-timestamps is inherently broken and also toml11 is breaking eval compat for it which is blocking the upgrade in Nixpkgs – https://github.com/NixOS/nix/pull/13741#issuecomment-3180851635 | 20:04:59 |
| emily | Sergei Zimmerman (xokdvium)'s patch restores the behaviour of the old toml11 version which seems good for stable releases but I'd suggest considering dropping the feature entirely | 20:05:30 |
 raitobezarius | Lord | 20:07:00 |
| raitobezarius | If I gather well, this is under a clear XP feature? | 20:07:46 |
| raitobezarius | So I would also lean on deletion | 20:08:25 |
 Sergei Zimmerman (xokdvium) | That'd be great | 20:08:48 |
| Sergei Zimmerman (xokdvium) | The fact that old tests didn't cover the most fucked semantics is infuriating | 20:09:25 |
| raitobezarius | Yeahh, I suppose I was too optimistic about Tom's small language being well behaving | 20:10:09 |
| raitobezarius | All these fromXYZ file format deserializers are ticking bombs :( | 20:10:34 |
| emily | yes, fromTOML by default rejects timestamps | 20:12:14 |
| emily | and I cannot find any evidence of anyone relying on this feature | 20:12:24 |
| emily | it was introduced for https://github.com/input-output-hk/foliage/issues/46 which didn't seem to ever happen | 20:12:31 |
| emily | (TOML is definitely not well-behaved. the top-level value can only be one type…) | 20:12:48 |
| Sergei Zimmerman (xokdvium) | https://toml.io/en/v1.0.0#local-time
Millisecond precision is required. Further precision of fractional seconds is implementation-specific.
FML
| 20:13:15 |
| emily | I think that the semantics that fromTOML exposes stably should be relatively safe; it's just that experimentally extending it to timestamps turns out to be more complicated than expected | 20:13:17 |
| emily | that fromTOML cannot handle all of TOML… is suboptimal, but oh well | 20:13:32 |
| emily | easier to expand than shrink :) | 20:13:47 |
| emily | I do think that the patch should be applied to stable releases, because breaking eval semantics even for experimental features in stable releases seems bad, and the Nixpkgs bump is blocked right now | 20:14:27 |
| emily | but +2 for dropping for next release | 20:14:40 |
| raitobezarius | Somehow obvious amirite | 20:15:06 |
| raitobezarius | Alright | 20:15:39 |
| raitobezarius | Taking away exp features from stable releases is a bit meh tho | 20:15:57 |
| emily | Sergei Zimmerman (xokdvium)'s patch doesn't take anything away | 20:16:16 |
| emily | (it computes the previous behaviour back on top of the new toml11) | 20:16:27 |
| emily | it's just an unfortunate amount of complexity for a broken feature that's clearly an eval stability liability, so I'd prefer to see a drop on HEAD | 20:17:01 |
| emily | doing it only for stable releases bounds the lifetime of the complexity | 20:17:21 |
| raitobezarius | Sorry, you're absolutely right | 20:17:58 |
| raitobezarius | That sounds like a good plan, patch for releases and drop for HEAD | 20:18:13 |
| raitobezarius | Thank you xokdvium for this! | 20:18:46 |
| Sergei Zimmerman (xokdvium) | Sure. I'll bring this issue up at the nix team meeting as well. I'd be in favor of dropping this feature on master. Digging through toml11 def wasn't a great experience. | 20:20:09 |
