Skip to content

Releases: chronotope/chrono

v0.4.30

07 Sep 14:52
Compare
Choose a tag to compare

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 (#1264, #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!

v0.4.29

05 Sep 15:41
Compare
Choose a tag to compare

This release fixes a panic introduced in chrono 0.4.27 in FromStr<DateTime<Utc>> (#1253).

Chrono now has a Discord channel.

Fixes

  • Fix arbitrary string slicing in parse_rfc3339_relaxed (#1254)

Deprecations

  • Deprecate TimeZone::datetime_from_str (#1251)

Documentation

  • Correct documentation for FromStr for Weekday and Month (#1226, thanks @wfraser)

Internal improvements

  • Revert "add test_issue_866" (#1238)
  • CI: run tests on i686 and wasm32-wasi (#1237)
  • CI: Include doctests for code coverage (#1248)
  • Move benchmarks to a separate crate (#1243)
    This allows us to upgrade the criterion dependency to 5.1 without changing our MSRV.
  • Add Discord link to README (#1240, backported in #1256)

Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!

v0.4.28

30 Aug 19:50
Compare
Choose a tag to compare

This release fixes a test failure on 32-bit targets introduced with 0.4.27, see #1234.

v0.4.27

29 Aug 14:01
Compare
Choose a tag to compare

This release bumps the MSRV from 1.56 to 1.57. This allows us to take advantage of the panicking in const feature. In this release most methods on NaiveDate and NaiveTime are made const, NaiveDateTime and others will follow in a later release.

The parser for the %+ formatting specifier and the RFC3339 formatting item is switched from a strict to a relaxed parser (see #1145). This matches the existing documentation, and the parser used by DateTime::from_str. If you need to validate the input, consider using DateTime::from_rfc3339.

Deprecations

  • Deprecate DateTime::{from_local, from_utc} (#1175)

Additions

  • Let DateTime::signed_duration_since take argument with Borrow (#1119)
  • Implement PartialOrd for Month (#999, thanks @Munksgaard)
  • Add Ord and Eq for types which already derive PartialOrd and PartialEq (#1128, thanks @totikom)
  • implement FusedIterator for NaiveDateDaysIterator and NaiveDateWeeksIterator (#1134)
  • Make NaiveDateDaysIterator and NaiveDateWeeksIterator public (#1134)
  • Add FromStr for FixedOffset (#1157, thanks @mcronce)
  • Remove Tz::Offset: Display requirement from DateTime::to_rfc* (#1160)
  • More flexible offset formatting (not exposed yet) (#1160)
  • Make StrftimeItems with unstable-locales work without allocating (#1152)
  • Make NaiveDate::from_ymd_opt const (#1172, thanks @kamadorueda)
  • Implement Error trait for ParseWeekdayError and ParseMonthError (#539, thanks @mike-kfed)
  • Make methods on NaiveTime const, update MSRV to 1.57 (#1080)
  • Make methods on NaiveDate const (#1205)
  • Implement operations for core::time::Duration on DateTime types (#1229)

Fixes

  • Ensure timestamp_nanos panics on overflow in release builds (#1123)
  • Fix offset_from_local_datetime for wasm_bindgen (#1131)
  • Parsing: Consider %s to be a timestamp in UTC (#1136)
  • Don't panic when formatting with %#z (#1140, thanks @domodwyer)
  • Parsing: allow MINUS SIGN (U+2212) in offset (#1087, thanks @jtmoon79)
  • Fix locale formatting for %c and %r (#1165)
  • Localize decimal point with unstable-locales feature (#1168)
  • Fix panic on macOS 10.12 caused by using version 1 of the TZif file format (#1201, thanks to help from @jfro)
  • Fix deserialization of negative timestamps (#1194)
  • Do not use Offset's Debug impl when serializing DateTime (#1035)
  • Allow missing seconds in NaiveTime::from_str (#1181)
  • Do not depend on android-tzdata if the clock feature is not enabled (#1220, thanks @AlexTMjugador)
  • Small fixes to the RFC 3339 parsers (#1145)

Documentation

  • Add "Errors" and "Panics" sections to API docs (#1120)
  • Specify licenses in SPDX format (#1132, backport of #910, thanks @LingMan)
  • Fix NaiveTime doc typo (#1146, thanks @zachs18)
  • Clarify nanosecond formatting specifier doc (#1173)
  • Add warning against combining multiple Datelike::with_* (#1199)
  • Fix typo "accepted" (#1209, thanks @simon04)
  • Add some examples to Utc::now and Local::now (#1192)
  • Add example to Weekday::num_days_from_monday (#1193)
  • Fix some comments and panic messages (#1221, thanks @umanwizard)

Internal improvements

  • DateTime::to_rfc_* optimizations (#1200)
  • Move all tests into modules, fix clippy warnings (#1138)
  • Offset parsing cleanup (#1158)
  • Factor out formatting to format/formatting.rs (#1156)
  • Format refactorings (#1198)
  • Format toml files with taplo (#1117, thanks @tottoto)
  • Stop vendoring saturating_abs (#1124)
  • CI: shell set -eux, use bash (#1103, thanks @jtmoon79)
  • Fix dead code error when running dateutils test on Windows (#1125)
  • Remove Makefile (#1133)
  • CI: Test wasm-bindgen feature (#1131)
  • Stop using deprecated methods in parse module (#1142)
  • Add formatting benchmarks (#1155)
  • Feature gate tests instead of methods (#1159, #1162)
  • Parallelize try_verify_against_date_command (#1161)
  • CI: also run integration tests with no_std (#1166)
  • Split test_parse (#1170)
  • Remove #![deny(dead_code)] (#1187)
  • Clippy fixes for Rust 1.71 (#1186)
  • Various small improvements (#1191)
  • Add unit test for uncovered regions (#1149, thanks @CXWorks)
  • Don't test the same thing twice in test_date_extreme_offset (#1195)
  • CI: Add workflow code coverage report and upload (#1178, #1215, thanks @jtmoon79)
  • CI: fail on warnings in features-check (#1216)
  • Switch to windows-bindgen (#1202, thanks to help from @MarijnS95)

Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!

v0.4.26

30 May 19:26
@djc djc
Compare
Choose a tag to compare

The changes from #807 we merged for 0.4.25 unfortunately restricted parsing in a way that was incompatible with earlier 0.4.x releases. We reverted this in #1113. A small amount of other changes were merged since.

Thanks on behalf of the chrono team (@djc and @esheppa) to all contributors!

v0.4.25

29 May 09:25
@djc djc
Compare
Choose a tag to compare

Time for another maintenance release. This release bumps the MSRV to 1.56; given MSRV bumps in chrono's dependencies (notably for syn 2), we felt that it no longer made sense to support any older versions. Feedback welcome in our issue tracker!

Additions

Fixes

  • Prevent string slicing inside char boundaries (#1024, thanks to @pitdicker)
  • fix IsoWeek so that its flags are always correct (#991, thanks to @moshevds)
  • Fix out-of-range panic in NaiveWeek::last_day (#1070, thanks to @pitdicker)
  • Use correct offset in conversion from Local to FixedOffset (#1041, thanks to @pitdicker)
  • Fix military timezones in RFC 2822 parsing (#1013, thanks to @pitdicker)
  • Guard against overflow in NaiveDate::with_*0 methods (#1023, thanks to @pitdicker)
  • Fix panic in from_num_days_from_ce_opt (#1052, thanks to @pitdicker)

Refactoring

Documentation

Internal improvements

On behalf of @djc and @esheppa, thanks to all contributors!

v0.4.24

12 Mar 20:31
@djc djc
Compare
Choose a tag to compare

This is a small maintenance release with accumulated fixes and improvements.

  • Fix doc on Days::new() to refer to days, not months (#874, thanks to @brotskydotcom)
  • Clarify out of range value for from_timestamp_opt() (#879, thanks to @xmo-odoo)
  • Add format_localized() for NaiveDate (#881, thanks to @mseele)
  • Fix bug in Add/Sub Days, add tests with DST timezone (#878)
  • Make NaiveTime::MIN public (#890)
  • Fix from_timestamp_millis() implementation and add more tests (#885)
  • Fix typo in docstrings (#897, thanks to @dandxy89)
  • Add test proving that #903 is fixed in 0.4.x head (#905, thanks to @umanwizard)
  • Add from_timestamp_micros() function (#906, thanks to @umanwizard)
  • Check cargo-deny in CI (#909)
  • Derive Hash for most pub types that also derive PartialEq (#938, thanks to @bruceg)
  • Update deprecated methods in from_utc() example (#939, thanks to @greg-el)
  • Fix panic in DateTime::checked_add_days() (#942, thanks to @Ekleog)
  • More documentation for dates before 1 BCE or after 9999 CE (#950, thanks to @cgit)
  • Improve FixedOffset docs (#953, thanks to @klnusbaum)
  • Add chrono-fuzz to CI and update its libfuzzer-sys dependency (#968, thanks to @LingMan)
  • Fixes to parsing and calculation of week numbers (#966, thanks to @raphaelroosz)
  • Make iana-time-zone a target specific dependency (#980, thanks to @krtab)
  • Make eligible functions const (#984, thanks to @tormeh)

Thanks to all contributors from the chrono team, @esheppa and @djc.

v0.4.23

12 Nov 07:58
@djc djc
Compare
Choose a tag to compare

0.4.23 is the next 0.4 release of the popular chrono date and time library for Rust. After the 0.4.20-0.4.22 series that brought chrono back to life after a long hiatus, development has been fairly quiet, allowing us to start planning changes for the 0.5.0 release. As such, we've started deprecating some APIs that are likely to be removed in 0.5. If you have any feedback on these changes, please let us know in the issue tracker!

Deprecations

  • Deprecate methods that have an _opt() alternative (#827)
  • Deprecate usage of the Date<Tz> type (#851)

Features

  • Optimize RFC 3339 (and RFC 2822) encoding (#844, thanks to @conradludgate)
  • Addition and subtraction with the Days type (#784)
  • Add NaiveDateTime::from_timestamp_millis(_opt) (#818, thanks to @Pscheidl -- backported in #823)
  • Allow for changing TZ variable and cache it for Local timezone (#853)
  • Add optional support for the arbitrary::Arbitrary trait (#849, thanks to @greyblake and @asayers)

Fixes

  • Support tzdb location on AIX (#826)
  • Fix warnings in documentation (#847)

On behalf of @esheppa and @djc, thanks to all contributors!

v0.4.22

13 Aug 13:43
@djc djc
Compare
Choose a tag to compare

Unfortunately the introduction of the iana-time-zone dependency in 0.4.21 caused some new regressions with lesser known platforms. This release fixes all of the issues we've encountered, improving the situation on some WebAssembly targets, SGX and on macOS/iOS. We've improved our CI setup to hopefully catch more of these issues before release in the future.

  • Make wasm-bindgen optional on wasm32-unknown-unknown target (#771)
  • Avoid iana-time-zone dependency on x86_64-fortanix-unknown-sgx (#767, thanks to @trevor-crypto)
  • Update iana-time-zone version to 0.1.44 to avoid cyclic dependencies (#773, thanks to @Kijewski for the upstream PRs)
  • Clarify documentation about year range in formatting/parsing (#765)

v0.4.21

09 Aug 15:36
@djc djc
Compare
Choose a tag to compare

0.4.21 is a bugfix release that mainly fixes one regression from 0.4.20:

  • Fall back to UTC in case no timezone is found. Unfortunately this is a regression from the changes we made in 0.4.20 where we now parse the timezone database ourselves. Before 0.4.20, TimeZone::now() fell back to UTC in the case it could not find the current timezone, but the new implementation panicked in that case.
  • Correctly detect timezone on Android (also #756). Android does have the timezone database installed, but it's in a different path, and it does not use /etc/localtime to keep track of the current timezone. Instead we now use the iana-time-zone crate as a dependency, since it already has quite a bit of logic for finding the current timezone on a host of platforms.

Additionally, there is a documentation fix that reverts an incorrect guarantee:

  • Document that %Y can have a negative value, both in formatting and in parsing (#760, thanks to @alex)