Skip to content
This repository has been archived by the owner on Oct 15, 2023. It is now read-only.

fix(deps): update rust crate chrono to 0.4.31 #48

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix(deps): update rust crate chrono to 0.4.31 #48

wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link

@renovate renovate bot commented May 28, 2023 •
edited
Loading

Mend Renovate

This PR contains the following updates:

Package Type Update Change
chrono dependencies patch 0.4.22 -> 0.4.31

Release Notes

chronotope/chrono (chrono)

v0.4.31: 0.4.31

Compare Source

Another maintenance release.
It was not a planned effort to improve our support for UNIX timestamps, yet most PRs seem related to this.

Deprecations
  • Deprecate timestamp_nanos in favor of the non-panicking timestamp_nanos_opt (#​1275)
Additions
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 and doc_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 on pure-rust-locales)

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

v0.4.30: 0.4.30

Compare Source

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
Documentation
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: 0.4.29

Compare Source

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
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: 0.4.28

Compare Source

This release fixes a test failure on 32-bit targets introduced with 0.4.27, see https://github.com/chronotope/chrono/issues/1234.

v0.4.27: 0.4.27

Compare Source

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 https://github.com/chronotope/chrono/pull/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

Additions

Fixes

Documentation

Internal improvements

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

v0.4.26: 0.4.26

Compare Source

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: 0.4.25

Compare Source

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
Refactoring
Documentation
Internal improvements

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

v0.4.24: 0.4.24

Compare Source

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

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

v0.4.23: 0.4.23

Compare Source

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
Fixes
  • Support tzdb location on AIX (#​826)
  • Fix warnings in documentation (#​847)

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

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

@renovate renovate bot added the renovate label May 28, 2023
@renovate renovate bot changed the title fix(deps): update rust crate chrono to 0.4.24 fix(deps): update rust crate chrono to 0.4.25 May 29, 2023
@renovate renovate bot force-pushed the renovate/chrono-0.4.x branch from 0906e72 to d8368ff Compare May 29, 2023 12:00
@renovate renovate bot changed the title fix(deps): update rust crate chrono to 0.4.25 fix(deps): update rust crate chrono to 0.4.26 May 30, 2023
@renovate renovate bot force-pushed the renovate/chrono-0.4.x branch from d8368ff to 4da8285 Compare May 30, 2023 20:12
@renovate renovate bot changed the title fix(deps): update rust crate chrono to 0.4.26 fix(deps): update rust crate chrono to 0.4.27 Aug 29, 2023
@renovate renovate bot force-pushed the renovate/chrono-0.4.x branch from 4da8285 to a70b3bc Compare August 29, 2023 16:27
@renovate renovate bot changed the title fix(deps): update rust crate chrono to 0.4.27 fix(deps): update rust crate chrono to 0.4.28 Aug 30, 2023
@renovate renovate bot force-pushed the renovate/chrono-0.4.x branch from a70b3bc to 2a07293 Compare August 30, 2023 21:40
@renovate renovate bot changed the title fix(deps): update rust crate chrono to 0.4.28 fix(deps): update rust crate chrono to 0.4.29 Sep 5, 2023
@renovate renovate bot force-pushed the renovate/chrono-0.4.x branch from 2a07293 to d2071d3 Compare September 5, 2023 16:43
@renovate renovate bot changed the title fix(deps): update rust crate chrono to 0.4.29 fix(deps): update rust crate chrono to 0.4.30 Sep 7, 2023
@renovate renovate bot force-pushed the renovate/chrono-0.4.x branch from d2071d3 to c641a58 Compare September 7, 2023 16:05
@renovate renovate bot changed the title fix(deps): update rust crate chrono to 0.4.30 fix(deps): update rust crate chrono to 0.4.31 Sep 15, 2023
@renovate renovate bot force-pushed the renovate/chrono-0.4.x branch from c641a58 to b9f86ba Compare September 15, 2023 16:54
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
renovate
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants