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.
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
rand crates. Of course chrono kept its dependency on this
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 had been a part of chrono's public API.
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
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
In November of 2020 CVE-2020-26235 and RUSTSEC-2020-0071 were opened against the
@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
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
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.