Replace chrono with time 0.3

[matze]

While the crate itself is not affected by RUSTSEC-2020-0159, crates depending on openidconnect still get flagged by cargo audit because the issue is still not fixed properly in chrono. Thus switch to time 0.3 which is not affected by either RUSTSEC-2020-0159 nor RUSTSEC-2020-0071.

[ramosbugs]

hey, thanks for the PR! it looks like this will make pretty substantial breaking changes to the public API (e.g., IdTokenClaims::expiration) and also increase the MSRV (I think to 1.50?).

I'm a bit conflicted, but I don't think this improvement alone (since it doesn't fix any real security issues, just false positives) is enough to justify a major version bump. However, it could make sense to bundle this with any future breaking changes as part of a larger release. I'd suggest fixing the CI errors (other than 1.45.0, which is incompatible), and then we can leave this PR open until some future date when there are more breaking changes needed.

[matze]

Thanks for the feedback and yes, I was afraid breaking the public API might be an issue. But then I wonder if that is such a big issue: why aren't we already at 1.x? Anyhow, I pushed the change that makes cargo test --all-features pass.

[ramosbugs]

Crossposting from ramosbugs/oauth2-rs#177:

The openidconnect crate is open for breaking changes again due to needing to bump its MSRV to 1.57, and I think this would be a good opportunity for the oauth2 crate to follow suit.

Now that chrono is being maintained again, it's not super clear to me which of the crates would be preferable to use. In either case, both oauth2 and openidconnect will need to expose both date/time and duration types via its public API that will couple it with a specific major version of chrono/time since there's no std type for representing dates.

If folks have opinions, please share them :-)

Both crates will either migrate to time or remain with chrono (potentially bumping to chrono 0.5 depending on when that's released).

[matze]

Hi, yes, the situation improved with chrono thankfully. Personally, I tend to use the smaller time crate if I don't need the additional features of chrono (timezone awareness, custom formatting, etc.) but now both being maintained by experienced Rust developers, I think you can use whatever you prefer from an API standpoint.