fix(deps): update rust crate chrono to 0.4.31
This MR contains the following updates:
Package | Type | Update | Change |
---|---|---|---|
chrono | dependencies | patch |
0.4.29 -> 0.4.31
|
Release Notes
chronotope/chrono (chrono)
v0.4.31
: 0.4.31
Another maintenance release. It was not a planned effort to improve our support for UNIX timestamps, yet most MRs seem related to this.
Deprecations
- Deprecate
timestamp_nanos
in favor of the non-panickingtimestamp_nanos_opt
(#1275)
Additions
- Add
DateTime::<Utc>::from_timestamp
(#1279, thanks @demurgos) - Add
TimeZone::timestamp_micros
(#1285, thanks @emikitas) - Add
DateTime<Tz>::timestamp_nanos_opt
andNaiveDateTime::timestamp_nanos_opt
(#1275) - Add
UNIX_EPOCH
constants (#1291)
Fixes
- Format day of month in RFC 2822 without padding (#1272)
- Don't allow strange leap seconds which are not on a minute boundary initialization methods (#1283)
This makes many methods a little more strict:
NaiveTime::from_hms_milli
NaiveTime::from_hms_milli_opt
NaiveTime::from_hms_micro
NaiveTime::from_hms_micro_opt
NaiveTime::from_hms_nano
NaiveTime::from_hms_nano_opt
NaiveTime::from_num_seconds_from_midnight
NaiveTime::from_num_seconds_from_midnight_opt
NaiveDate::and_hms_milli
NaiveDate::and_hms_milli_opt
NaiveDate::and_hms_micro
NaiveDate::and_hms_micro_opt
NaiveDate::and_hms_nano
NaiveDate::and_hms_nano_opt
NaiveDateTime::from_timestamp
NaiveDateTime::from_timestamp_opt
TimeZone::timestamp
TimeZone::timestamp_opt
- Fix underflow in
NaiveDateTime::timestamp_nanos_opt
(#1294, thanks @crepererum)
Documentation
- Add more documentation about the RFC 2822 obsolete date format (#1267)
Internal
- Remove internal
__doctest
feature anddoc_comment
dependency (#1276) - CI: Bump
actions/checkout
from 3 to 4 (#1280) - Optimize
NaiveDate::add_days
for small values (#1214) - Upgrade
pure-rust-locales
to 0.7.0 (#1288, thanks @jeremija wo did good improvements onpure-rust-locales
)
Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
v0.4.30
: 0.4.30
In this release, we have decided to swap out the chrono::Duration
type (which has been a re-export of time 0.1 Duration
type) with our own definition, which exposes a strict superset of the time::Duration
API. This helps avoid warnings about the CVE-2020-26235 and RUSTSEC-2020-0071 advisories for downstream users and allows us to improve the Duration
API going forward.
While this is technically a SemVer-breaking change, we expect the risk of downstream users experiencing actual incompatibility to be exceedingly limited (see our analysis of public code using a crater-like experiment), and not enough justification for the large ecosystem churn of a 0.5 release. If you have any feedback on these changes, please let us know in #1268.
Additions
- Add
NaiveDate::leap_year
(#1261)
Documentation
- Update main documentation from README (#1260, thanks @Stygmates)
- Add history of relation between chrono and time 0.1 to documentation (https://github.com/chronotope/chrono/pull/1264, https://github.com/chronotope/chrono/pull/1266)
- Clarify
Timelike::num_seconds_from_midnight
is a simple mapping (#1255)
Relation between chrono and time 0.1
Rust first had a time
module added to std
in its 0.7 release. It later moved to libextra
, and then to a libtime
library shipped alongside the standard library. In 2014 work on chrono started in order to provide a full-featured date and time library in Rust. Some improvements from chrono made it into the standard library; notably, chrono::Duration
was included as std::time::Duration
(rust#15934) in 2014.
In preparation of Rust 1.0 at the end of 2014 libtime
was moved out of the Rust distro and into the time
crate to eventually be redesigned (rust#18832, rust#18858), like the num
and rand
crates. Of course chrono kept its dependency on this time
crate. time
started re-exporting std::time::Duration
during this period. Later, the standard library was changed to have a more limited unsigned Duration
type (rust#24920, RFC 1040), while the time
crate kept the full functionality with time::Duration
. time::Duration
had been a part of chrono's public API.
By 2016 time
0.1 lived under the rust-lang-deprecated
organisation and was not actively maintained (time#136). chrono absorbed the platform functionality and Duration
type of the time
crate in chrono#478 (the work started in chrono#286). In order to preserve compatibility with downstream crates depending on time
and chrono
sharing a Duration
type, chrono kept depending on time 0.1. chrono offered the option to opt out of the time
dependency by disabling the oldtime
feature (swapping it out for an effectively similar chrono type). In 2019, @jhpratt took over maintenance on the time
crate and released what amounts to a new crate as time
0.2.
Security advisories
In November of 2020 CVE-2020-26235 and RUSTSEC-2020-0071 were opened against the time
crate. @quininer had found that calls to localtime_r
may be unsound (chrono#499). Eventually, almost a year later, this was also made into a security advisory against chrono as RUSTSEC-2020-0159, which had platform code similar to time
.
On Unix-like systems a process is given a timezone id or description via the TZ
environment variable. We need this timezone data to calculate the current local time from a value that is in UTC, such as the time from the system clock. time
0.1 and chrono used the POSIX function localtime_r
to do the conversion to local time, which reads the TZ
variable.
Rust assumes the environment to be writable and uses locks to access it from multiple threads. Some other programming languages and libraries use similar locking strategies, but these are typically not shared across languages. More importantly, POSIX declares modifying the environment in a multi-threaded process as unsafe, and getenv
in libc can't be changed to take a lock because it returns a pointer to the data (see rust#27970 for more discussion).
Since version 4.20 chrono no longer uses localtime_r
, instead using Rust code to query the timezone (from the TZ
variable or via iana-time-zone
as a fallback) and work with data from the system timezone database directly. The code for this was forked from the tz-rs crate by @x-hgg-x. As such, chrono now respects the Rust lock when reading the TZ
environment variable. In general, code should avoid modifying the environment.
Removing time 0.1
Because time 0.1 has been unmaintained for years, however, the security advisory mentioned above has not been addressed. While chrono maintainers were careful not to break backwards compatibility with the time::Duration
type, there has been a long stream of issues from users inquiring about the time 0.1 dependency with the vulnerability. We investigated the potential breakage of removing the time 0.1 dependency in chrono#1095 using a crater-like experiment and determined that the potential for breaking (public) dependencies is very low. We reached out to those few crates that did still depend on compatibility with time 0.1.
As such, for chrono 0.4.30 we have decided to swap out the time 0.1 Duration
implementation for a local one that will offer a strict superset of the existing API going forward. This will prevent most downstream users from being affected by the security vulnerability in time 0.1 while minimizing the ecosystem impact of semver-incompatible version churn.
Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
Configuration
-
If you want to rebase/retry this MR, check this box
This MR has been generated by Renovate Bot.