Skip to content

Using time crate instead of chrono #533

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Nov 19, 2021
Merged

Conversation

HallerPatrick
Copy link
Contributor

This PR solves Issue #526.

I ported, more or less, the chrono-humanize library to only use the std lib time and as a optional feature the time-rs crate ( for display iso time). Because I wanted to keep most of tests of the original repo (which are a lot!) and also included some nice interface, I made this an own crate.

The code now even looks way cleaner and include less logic. I tested the human readable output as well as the iso output on different repos. Feel free to test this as well.

@HallerPatrick HallerPatrick added discussion dependencies Pull requests that update a dependency file labels Nov 17, 2021
@HallerPatrick HallerPatrick added this to the v2.11.0 milestone Nov 17, 2021
@HallerPatrick
Copy link
Contributor Author

Looks like the audit finds a soundness issue for chrono and time. time is an optional feature of time-humanize, that is used to display the time as the iso standard. I am not sure if this is affecting our use case.

Copy link
Collaborator

@spenserblack spenserblack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like chrono is still in our dependency tree because it's a build dependency of tokei, but I think that's OK.
I didn't see the advisory for time that you mentioned, though.

Comment on lines 341 to +350
fn git_time_to_formatted_time(time: &Time, iso_time: bool) -> String {
let (offset, _) = match time.offset_minutes() {
n if n < 0 => (-n, '-'),
n => (n, '+'),
};

let offset = FixedOffset::west(offset);
let dt_with_tz = offset.timestamp(time.seconds(), 0);
if iso_time {
dt_with_tz
.with_timezone(&chrono::Utc)
.to_rfc3339_opts(chrono::SecondsFormat::Secs, true)
to_rfc3339(HumanTime::from(time.seconds()))
} else {
let ht = HumanTime::from(dt_with_tz);
let ht = HumanTime::from_duration_since_timestamp(time.seconds().unsigned_abs());
format!("{}", ht)
}
}

fn to_rfc3339<T>(dt: T) -> String
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be cool if we added some tests for these functions. Unfortunately we didn't have any prior tests for duration formatting to confirm consistent behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, can do that

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spenserblack You think those tests are sufficient?

Co-authored-by: Spenser Black <[email protected]>
@spenserblack
Copy link
Collaborator

Sorry @HallerPatrick, I gave you a bad suggestion. See #533 (comment)

@HallerPatrick
Copy link
Contributor Author

Looks like chrono is still in our dependency tree because it's a build dependency of tokei, but I think that's OK.
I didn't see the advisory for time that you mentioned, though.

In the audit there is a reference link, which leads to the time-rs repo. chrono and time have the same unsoundness bug. time-rs issue , chrono issue

@spenserblack
Copy link
Collaborator

Got it, thanks for linking the issue!
According to this security advisory and time-rs/time#293 (comment) it seems that time >= 0.2.23 won't be affected. In this PR both onefetch and time-humanize depend on 0.3.5, so it looks OK in my opinion.
The affected time version (0.1) comes from chrono, which through the chain of dependencies is a build dependency of tokei. I think that it's out of our scope to fix deeply nested build dependencies of one of our dependencies 🙂

tl;dr it doesn't seem like we have to worry about time's security advisory IMO

Copy link
Collaborator

@spenserblack spenserblack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding the tests, LGTM!

@HallerPatrick
Copy link
Contributor Author

@o2sh does not seem to be active currently. Because I got your okay, I would merge this now

@o2sh
Copy link
Owner

o2sh commented Nov 20, 2021

So sorry I couldn't find the time to review your PR @HallerPatrick 😞
Thanks @spenserblack for providing great feedback as always 💪

Everything seems to work as expected.

My only concern is the edition = "2021" used by time-humanize which makes onefetch's msrv (minimum supported rust version) go from 1.50.0 to 1.56.1

Rust version 1.56.1 is very recent and not yet available for launchpad

@HallerPatrick
Copy link
Contributor Author

So sorry I couldn't find the time to review your PR @HallerPatrick 😞

Thanks @spenserblack for providing great feedback as always 💪

Everything seems to work as expected.

My only concern is the edition = "2021" used by time-humanize which makes onefetch's msrv (minimum supported rust version) go from 1.50.0 to 1.56.1

Rust version 1.56.1 is very recent and not yet available for launchpad

No problem at all. @spenserblack gave good feedback.

For time-humanize: I was not aware of the Edition difference. I will look to lower it to onefetchs version if possible.

@HallerPatrick
Copy link
Contributor Author

@o2sh I updated the rust version of time-humanize to edition = "2018". Would you update the dependency to time-humanize = { version="0.1.3", features = ["time"] }? Or should I do this through a PR?

@o2sh
Copy link
Owner

o2sh commented Nov 21, 2021

Thanks @HallerPatrick 👍
I think we can wait for the dependabot to take care of it 🤖

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file discussion
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants