This change should not have any semantic meaning and is being done to address RUSTSEC-2020-0071 (see #244) and RUSTSEC-20200159 (see #245).
This is a breaking API change because some result types include create/updated timestamps. Consumers of the library will need to add a direct dependency on time. Note that chrono already uses time internally, so this change should not bloat transitive dependencies.
For those needing serialization support of OffsetDateTime timestamps, the time crate offers this support with the serde feature flag.
One small point of friction here is rfc3339 support. time has this support on a branch that is blocked on a rust feature hitting stable, so I copied in a few lines of code from that branch to support deserializing rfc3339 timestamps.
Closes #244 #245
This change should not have any semantic meaning and is being done to address RUSTSEC-2020-0071 (see #244) and RUSTSEC-20200159 (see #245).
This is a breaking API change because some result types include create/updated timestamps. Consumers of the library will need to add a direct dependency on
time. Note thatchronoalready usestimeinternally, so this change should not bloat transitive dependencies.For those needing serialization support of
OffsetDateTimetimestamps, thetimecrate offers this support with theserdefeature flag.One small point of friction here is rfc3339 support.
timehas this support on a branch that is blocked on a rust feature hitting stable, so I copied in a few lines of code from that branch to support deserializing rfc3339 timestamps.To fully fix the RUSTSEC advisories, it was necessary to upgrade one of our dependencies as well. See https://github.com/Keats/jsonwebtoken/pull/222
For now, this PR depends on https://github.com/IronCoreLabs/jsonwebtoken.