Date and time library for Rust
This release bring a ca. 20% improvement to the performance of the formatting code, and a convenient days_since
method for the Weekday
type.
Chrono 0.4.38 also removes the long deprecated rustc-serialize
feature. Support for rustc-serialize
will be soft-destabilized in the next Rust edition. Removing the feature will not break existing users of the feature; Cargo will just not update dependents that rely on it to newer versions of chrono.
In chrono 0.4.36 we made an accidental breaking change by switching to derive(Copy)
for DateTime
instead of a manual implementation. It is reverted in this release.
rustc-serialize
feature (#1548, thanks @workingjubilee)Weekday::days_since
(#1249, based on #216 by @clarfonthey)TimeDelta::checked_mul
and TimeDelta::checked_div
(#1565, thanks @Zomtir)Copy
for DateTime
if offset is Copy
(#1573)test_encodable_json
and test_decodable_json
functions (#1550)cargo hack check
(#1553)Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
Version 0.4.36 introduced an unexpected breaking change and was yanked. In it LocalResult
was renamed to MappedLocalTime
to avoid the impression that it is a Result
type were some of the results are errors. For backwards compatibility a type alias with the old name was added.
As it turns out there is one case where a type alias behaves differently from the regular enum: you can't import enum variants from a type alias with use chrono::LocalResult::*
. With 0.4.37 we make the new name MappedLocalTime
the alias, but keep using it in function signatures and the documentation as much as possible.
See also the release notes of chrono 0.4.36 from yesterday for the yanked release.
This release un-deprecates the methods on TimeDelta
that were deprecated with the 0.4.35 release because of the churn they are causing for the ecosystem.
New is the DateTime::with_time()
method. As an example of when it is useful:
use chrono::{Local, NaiveTime};
// Today at 12:00:00
let today_noon = Local::now().with_time(NaiveTime::from_hms_opt(12, 0, 0).unwrap());
DateTime::with_time()
(#1510)TimeDelta
deprecations (#1543)TimeStamp::timestamp_subsec_nanos
, which was missed in the 0.4.35 release (#1486)Copy
and Send
impls (#1492, thanks @erickt)NaiveDate
unit tests (#1500, thanks @Zomtir)LocalResult
to TzResolution
, add alias (#1501)NaiveDate::from_yof
(#1518)DateTime::date_naive
and NaiveDate::diff_months
(#1530)unwrap
in Unix Local
type (#1533)Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
Most of our efforts have shifted to improving the API for a 0.5 release, for which cleanups and refactorings are landing on the 0.4.x branch.
The most significant changes in this release are two sets of deprecations.
We deprecated all timestamp-related methods on NaiveDateTime
. The reason is that a timestamp is defined to be in UTC. The NaiveDateTime
type doesn't know the offset from UTC, so it was technically wrong to have these methods. The alternative is to use the similar methods on the DateTime<Utc>
type, or from the TimeZone
trait.
Converting from NaiveDateTime
to DateTime<Utc>
is simple with .and_utc()
, and in the other direction with .naive_utc()
.
The panicking constructors of TimeDelta
(the new name of the Duration
type) are deprecated. This was the last part of chrono that defaulted to panicking on error, dating from before rust 1.0.
A nice change is that NaiveDate
now includes a niche. So now Option<NaiveDate>
, Option<NaiveDateTime>
and Option<DateTime<Tz>>
are the same size as their base types.
format::Numeric
and format::Fixed
are marked as non_exhaustive
. This will allow us to improve our formatting and parsing support, and we have reason to believe this breaking change will have little to no impact on users.
DateTime::{from_timestamp_micros, from_timestamp_nanos}
(#1234)Parsed
(#1465)NaiveDateTime
(#1473)TimeDelta
(#1450)NonZeroI32
inside NaiveDate
(#1207)format::Numeric
and format::Fixed
as non_exhaustive
(#1430)Parsed
fixes to error values (#1439)overflowing_naive_local
in DateTime::checked_add*
(#1333)Parsed::set_*
(#1465)Parsed
(#1439)internals
module (#1428, #1429, #1431, #1432, #1433, #1438)x86_64-unknown-illumos
instead of Solaris (#1437)cargo hack check
on Linux (#1442)parse_internal
(#1459)SerdeError
(#1458)NaiveDate::from_isoywd
a bit (#1464)Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
Duration
type to TimeDelta
. This removes the confusion between chrono's type and the later Duration
type in the standard library. It will remain available under the old name as a type alias for compatibility.Local
is rewritten. The new version avoids panics when the date is outside of the range supported by windows (the years 1601 to 30828), and gives more accurate results during DST transitions.Display
format of TimeDelta
is modified to conform better to ISO 8601. Previously it converted all values greater than 24 hours to a value with days. This is not correct, as doing so changes the duration from an 'accurate' to a 'nominal' representation to use ISO 8601 terms.TimeDelta::milliseconds
(#1385, thanks @danwilliams)DurationExceedsTimestamp
in DurationRound
(#1403, thanks @joroKr21)%X
(https://github.com/chronotope/pure-rust-locales/pull/12, #1420)GetTimeZoneInformationForYear
(#1017)TimeDelta::try_milliseconds
(#1385, thanks @danwilliams)TimeDelta::new
(#1337)StrftimeItems::{parse, parse_to_owned}
and more documentation (#1184)format::Locale
(via https://github.com/chronotope/pure-rust-locales/pull/8)Duration
to TimeDelta
, add type alias (#1406)TimeDelta
methods const (#1337)NaiveDate
, NaiveWeek
, NaiveTime
and NaiveDateTime
const where possible (#1337)DateTime
const where possible (#1400)Display
format of TimeDelta
conform better to ISO 8601 (#1328)timestamp_micros
's Example doc (#1338 via #1386, thanks @emikitas)TimeDelta
constructors (#1385, thanks @danwilliams)main
branch, work on 0.5 happens in the 0.5.x
branch (#1390, #1402).impl Arbitrary for DateTime
and set up CI test (#1336)codecov/codecov-action
from 3 to 4 (#1404)-0000
offset (#1411)TOO_LONG
error out of parse_internal
(#1419)Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
This release fixes the broken docrs.rs build of chrono 0.4.32.
rkyv
feature imply size_32
(#1383)Duration::hours()
exception (#1384, thanks @danwilliams)In this release we shipped part of the effort to reduce the number of methods that could unexpectedly panic, notably for the DateTime
and Duration
types.
Chrono internally stores the value of a DateTime
in UTC, and transparently converts it to the local value as required. For example adding a second to a DateTime
needs to be done in UTC to get the correct result, but adding a day needs to be done in local time to be correct. What happens when the value is near the edge of the representable range, and the implicit conversions pushes it beyond the representable range? Many methods could panic on such inputs, including formatting the value for Debug
output.
In chrono 0.4.32 the range of NaiveDate
, NaiveDateTime
and DateTime
is made slightly smaller. This allows us to always do the implicit conversion, and in many cases return the expected result. Specifically the range is now from January 1, -262144 until December 31, 262143, one year less on both sides than before. We expect this may trip up tests if you hardcoded the MIN
and MAX
dates.
Duration
had a similar issue. The range of this type was pretty arbitrary picked to match the range of an i64
in milliseconds. Negating an i64::MIN
pushes a value out of range, and in the same way negating Duration::MIN
could push it out of our defined range and cause a panic. This turns out to be somewhat common and hidden behind many layers of abstraction. We adjusted the type to have a minimum value of -Duration::MAX
instead and prevent the panic case.
Other highlights:
Duration
gained new fallible initialization methods.rkyv
.NaiveDateTime
are now const.DateTime
const in a future release.Complete list of changes:
TimeZone::from_local_datetime
(#1071)DateTime
getters and setters (#1317, #1329)NaiveDateTime::checked_(add|sub)_offset
(#1313)DateTime::to_utc
(#1325)Default
for Duration
(#1327)Duration::subsec_nanos
(#1327)try_*
builders to Duration
(#1327)AddAssign
and SubAssign
for Duration
(#1327)NaiveDateTime
const where possible (#1286)clock
feature into clock
and now
(#1343, thanks @mmastrac)From<NaiveDate>
for NaiveDateTime
(#1355, thanks @dcechano)NaiveDateTime::from_timestamp_nanos
(#1357, thanks @Ali-Mirghasemi)Months::num_months()
and num_years()
(#1373, thanks @danwilliams)DateTime<Utc>::from_timestamp_millis
(#1374, thanks @xmakro)Duration::MIN.abs()
(adjust Duration::MIN
by 1 millisecond) (#1334)format
functions (#1306)doc_auto_cfg
(#1305, #1326)Add
/Sub
impls and use expect
(#1316)TimeZone::datetime_from_str
(#1342, thanks @tmccombs)Datelike
impl for DateTime
(#1376, thanks @ElectrifyPro)Archived*
types in rkyv
module (#1304)Archived*
types (#1271, thanks @Awpteamoose)unstable-locales
imply the alloc
feature (#1307)format::{format_localized, format_item_localized}
(#1311)write_rfc2822_inner
, don't localize (#1322)DateTime::with_*
(#1309)*_DAYS_FROM_YEAR_0
calculation (#1312)NaiveTime::overflowing_(add|sub)_offset
(#1310)DateTime::overflowing_(add|sub)_offset
(#1069)set env LC_ALL
(#1315, thanks @jtmoon79)deny.toml
(#1320)with: node-version
(#1352, thanks @jtmoon79)toml
job (#1371, thanks @gibbz00)Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
Another maintenance release. It was not a planned effort to improve our support for UNIX timestamps, yet most PRs seem related to this.
timestamp_nanos
in favor of the non-panicking timestamp_nanos_opt
(#1275)DateTime::<Utc>::from_timestamp
(#1279, thanks @demurgos)TimeZone::timestamp_micros
(#1285, thanks @emikitas)DateTime<Tz>::timestamp_nanos_opt
and NaiveDateTime::timestamp_nanos_opt
(#1275)UNIX_EPOCH
constants (#1291)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
NaiveDateTime::timestamp_nanos_opt
(#1294, thanks @crepererum)__doctest
feature and doc_comment
dependency (#1276)actions/checkout
from 3 to 4 (#1280)NaiveDate::add_days
for small values (#1214)pure-rust-locales
to 0.7.0 (#1288, thanks @jeremija wo did good improvements on pure-rust-locales
)Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
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.
NaiveDate::leap_year
(#1261)Timelike::num_seconds_from_midnight
is a simple mapping (#1255)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.
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.
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!