-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Replace time crate with jiff #15293
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
base: master
Are you sure you want to change the base?
Replace time crate with jiff #15293
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,9 +11,10 @@ use cargo_credential::{ | |
}; | ||
|
||
use core::fmt; | ||
use jiff::Timestamp; | ||
use serde::Deserialize; | ||
use std::error::Error; | ||
use time::{Duration, OffsetDateTime}; | ||
use std::time::Duration; | ||
use url::Url; | ||
|
||
use crate::core::SourceId; | ||
|
@@ -619,7 +620,7 @@ fn auth_token_optional( | |
if let Some(cached_token) = cache.get(url) { | ||
if cached_token | ||
.expiration | ||
.map(|exp| OffsetDateTime::now_utc() + Duration::minutes(1) < exp) | ||
.map(|exp| Timestamp::now() + Duration::from_secs(60) < exp) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Small thing, but you could do There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there some benefit to use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You get the from_mins constructor. But otherwise, in this case, no. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. especially sicne you use the above suggestion in your changes to |
||
.unwrap_or(true) | ||
{ | ||
if cached_token.operation_independent || matches!(operation, Operation::Read) { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this a public API change and needs a major version bump?
Wonder why
cargo-semver-checks
didn't report to us.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If so, should we wait for jiff 1.0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or change it to other integer type or wrapper type, so it is completely opaque.
There is no guarantee that jiff@2 won't come out a week after jiff@1 is out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree an integer or wrapper type makes sense for something like this.
Just to comment on this, it is my intent that
jiff
will stay at 1.0 indefinitely. For ajiff 2.0
to happen a week or even 1 month afterjiff 1.0
is released, I think something spectacular would have had to go wrong.Otherwise, I do have a track record of sticking to 1.0.
regex
is still at 1.0 even though there are mistakes in its API I would like to fix. Same withbstr
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @BurntSushi! I totally agree with it and fully trust you as a maintainer of those awesome crates. I meant to express that regardless it is 0.2 or 1.0, a major version bump is a major version bump. If we have fear of re-export we should make it opaque.
Sorry I didn't mean to make you feel bad 😞.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No I didn't feel bad, I just want to make sure the right kinds of expectations are telegraphed. :) I just mean it would be a spectacular failure on my part if 2.0 were released right after 1.0.
My plan is to release Jiff 1.0 this summer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes and we already had this problem with
time
in the puiblic API. I was just wondering if we should consolidate the breaking changes or going ahead and moving forward. No strong opinion. So long as the serialization format is unchanged, breaking changes to this API are not too big of a deal; the target audience is very small.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the braking changes (whatever they are) be done in another PR before this? Or in this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are removing
time
in this PR, the breaking change seems better to be in the same PR. Could be one more commit if needed.Slightly prefer the approach making it opaque. Not really strong though.