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

[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.