Replace humantime dependency for jiff

[killzoner]

Hello,

Just recently humantime was referenced as RUSTSEC. This PR replaces it with jiff

Solving https://github.com/rustsec/advisory-db/blob/a99f72f78f43ef5b7883126f5454d86d8670b97d/crates/humantime/RUSTSEC-2025-0014.md?plain=1#L4

Not sure if the parsing of this is covered by tests though

[BurntSushi]

Is status.duration a std::time::Duration? If so, consider SignedDuration::try_from(duration).unwrap(), which will have an explicit panic instead of a silent truncation.

[epage]

I was not sure if we assumed panic was allowed in this context, but I see now it's already used at various places
Just updated the PR with your code (and thanks for jiff 😄)

Think of unwrap as an assert with such a clear intention that it doesn't need more clarification.

There are different ways of thinking of this

• If a test were to take longer than i64 can represent, that is highly unusual and a panic isn't too bad. In that case, we should document that with an .expect()
• If a test takes longer than a i64 can represent, we should still report results and it would be fine to leave the value at i64::MAX
• If a test takes longer than a i64 can represent, we should still report results and we should indicate that the test too longer than we could track

[epage]

This was marked as resolved yet unwrap() is still being used

[killzoner]

My bad, i will go back to this

[killzoner]

Thank you for the swift review @BurntSushi .
I was not sure if we assumed panic was allowed in this context, but I see now it's already used at various places
Just updated the PR with your code (and thanks for jiff 😄)

[coveralls]

Pull Request Test Coverage Report for Build 13818241505

Details

• 6 of 12 (50.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.001%) to 50.304%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
crates/trycmd/src/runner.rs	2	4	50.0%
crates/trycmd/src/schema.rs	4	8	50.0%

Totals
Change from base Build 13442512539:	-0.001%
Covered Lines:	1408
Relevant Lines:	2799

---

💛 - Coveralls

[killzoner]

From what I see, the MSRV check is a bit puzzling
The CI claims for 1.65 in https://github.com/assert-rs/snapbox/actions/runs/13814189460/job/38644006078, but I see in changelog that at least trycmd and snapbox have bumped to 1.70 (which corresponds to jiff's one)

snapbox/crates/trycmd/CHANGELOG.md

Line 83 in fbcd538

- MSRV bumped to 1.70.0

snapbox/crates/trycmd/CHANGELOG.md

Line 83 in fbcd538

- MSRV bumped to 1.70.0

I would upgrade the one in https://github.com/assert-rs/snapbox/blob/main/Cargo.toml#L9 to 1.70 but maybe there is something off here

[epage]

I unofficially lowered the MSRV as an experiment. It should be fine to bump it up to 1.70 though that should be its own commit.

[epage]

Was an empty string previously supported?

[killzoner]

Will look into humantime implementation

[BurntSushi]

humantime::parse_duration reports an error for empty strings (as Jiff does).

[killzoner]

Apparently there has been an initiative from the chrono project to take over the humantime crate and maintain it from now (a new updated version has already been pushed)
I don't see any such activity for humantime-serde though.

As trycmd uses both of them, I'm gonna address the remaining comments, but it might just be worth waiting to see if the second crate also gets activity again and update existing lock, even though I think jiff is probably gonna get much more updates

[killzoner]

As someone said at a meetup in Paris today, sometimes it's better to close a PR 😄
Thank you both for you time, I learned a few things along the way

[epage]

Actually, I'm for these transitions to happen anyways. I was already interested in moving away from time to jiff and humantime being unmaintained was just the excuse to do so.