appender: replace chrono with time #1652
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hawkw
reviewed
Oct 19, 2021
|
hmm looks like including the macros as a dev dependency still breaks MSRV. can we drop them from the tests as well? |
hawkw
approved these changes
Oct 21, 2021
| @@ -21,7 +21,7 @@ jobs: | |||
| uses: actions-rs/cargo@v1 | |||
| with: | |||
| command: check | |||
| args: --all | |||
| args: --all --exclude=tracing-appender | |||
There was a problem hiding this comment.
can we also update the MSRV in tracing-appender's documentation & readme?
hawkw
requested changes
Oct 21, 2021
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
…hub.com/tokio-rs/tracing into davidbarsky/once-upon-a-time-in-tracing
hawkw
approved these changes
Oct 22, 2021
hawkw
pushed a commit
that referenced
this pull request
Oct 22, 2021
## Motivation This PR continues the work started in #1646 to replace `chrono` with `time`. I'll refer to @hawkw's motivation: > Currently, `tracing-subscriber` supports the `chrono` crate for > timestamp formatting, via a default-on feature flag. When this code > was initially added to `tracing-subscriber`, the `time` crate did not > have support for the timestamp formatting options we needed. > > Unfortunately, the `chrono` crate's maintenance status is now in > question (see #1598). Furthermore, `chrono` depends on version 0.1 of > the `time` crate, which contains a security vulnerability > (https://rustsec.org/advisories/RUSTSEC-2020-0071.html). This > vulnerability is fixed in more recent releases of `time`, but `chrono` > still uses v0.1. ## Solution I've replaced chrono with time 0.3. Unfortunately, some of chrono's builders for DateTimes are not present in `time`, which required the usage of `macro_rules!` macros to construct some of the hard-coded times. I also took the opportunity to tidy some of the tests and change the internal representation of `Rotation::NEVER` from year 9,999 to an `Option::None`. This branch changes `tracing-appender`'s MSRV from Rust 1.42 to Rust 1.51, the MSRV for the `time` crate when certain required feature flags are enabled. This does *not* effect the MSRV for other crates in this repository.
hawkw
pushed a commit
that referenced
this pull request
Oct 22, 2021
## Motivation This PR continues the work started in #1646 to replace `chrono` with `time`. I'll refer to @hawkw's motivation: > Currently, `tracing-subscriber` supports the `chrono` crate for > timestamp formatting, via a default-on feature flag. When this code > was initially added to `tracing-subscriber`, the `time` crate did not > have support for the timestamp formatting options we needed. > > Unfortunately, the `chrono` crate's maintenance status is now in > question (see #1598). Furthermore, `chrono` depends on version 0.1 of > the `time` crate, which contains a security vulnerability > (https://rustsec.org/advisories/RUSTSEC-2020-0071.html). This > vulnerability is fixed in more recent releases of `time`, but `chrono` > still uses v0.1. ## Solution I've replaced chrono with time 0.3. Unfortunately, some of chrono's builders for DateTimes are not present in `time`, which required the usage of `macro_rules!` macros to construct some of the hard-coded times. I also took the opportunity to tidy some of the tests and change the internal representation of `Rotation::NEVER` from year 9,999 to an `Option::None`. This branch changes `tracing-appender`'s MSRV from Rust 1.42 to Rust 1.51, the MSRV for the `time` crate when certain required feature flags are enabled. This does *not* effect the MSRV for other crates in this repository.
hawkw
added a commit
that referenced
this pull request
Oct 22, 2021
# 0.2.0 (October 22, 2021) This breaking change release adds support for the new v0.3.x series of `tracing-subscriber`. In addition, it resolves the security advisory for the `chrono` crate, [RUSTSEC-2020-0159]. This release increases the minimum supported Rust version (MSRV) to 1.51.0. ### Breaking Changes - Updated `tracing-subscriber` to v0.3.x ([#1677]) - Changed `NonBlocking::error_counter` to return an `ErrorCounter` type, rather than an `Arc<AtomicU64>` ([#1675]) ### Changed - Updated `tracing-subscriber` to v0.3.x ([#1677]) ### Fixed - **non-blocking**: Fixed compilation on 32-bit targets ([#1675]) - **rolling**: Replaced `chrono` dependency with `time` to resolve [RUSTSEC-2020-0159] ([#1652]) - **rolling**: Fixed an issue where `RollingFileAppender` would fail to print errors that occurred while flushing a previous logfile ([#1604]) Thanks to new contributors @dzvon and @zvkemp for contributing to this release! [RUSTSEC-2020-0159]: https://rustsec.org/advisories/RUSTSEC-2020-0159.html [#1677]: #1677 [#1675]: #1675 [#1652]: #1675 [#1604]: #1604
hawkw
added a commit
that referenced
this pull request
Oct 23, 2021
# 0.2.0 (October 22, 2021) This breaking change release adds support for the new v0.3.x series of `tracing-subscriber`. In addition, it resolves the security advisory for the `chrono` crate, [RUSTSEC-2020-0159]. This release increases the minimum supported Rust version (MSRV) to 1.51.0. ### Breaking Changes - Updated `tracing-subscriber` to v0.3.x ([#1677]) - Changed `NonBlocking::error_counter` to return an `ErrorCounter` type, rather than an `Arc<AtomicU64>` ([#1675]) ### Changed - Updated `tracing-subscriber` to v0.3.x ([#1677]) ### Fixed - **non-blocking**: Fixed compilation on 32-bit targets ([#1675]) - **rolling**: Replaced `chrono` dependency with `time` to resolve [RUSTSEC-2020-0159] ([#1652]) - **rolling**: Fixed an issue where `RollingFileAppender` would fail to print errors that occurred while flushing a previous logfile ([#1604]) Thanks to new contributors @dzvon and @zvkemp for contributing to this release! [RUSTSEC-2020-0159]: https://rustsec.org/advisories/RUSTSEC-2020-0159.html [#1677]: #1677 [#1675]: #1675 [#1652]: #1675 [#1604]: #1604
kaffarell
pushed a commit
to kaffarell/tracing
that referenced
this pull request
May 22, 2024
This PR continues the work started in tokio-rs#1646 to replace `chrono` with `time`. I'll refer to @hawkw's motivation: > Currently, `tracing-subscriber` supports the `chrono` crate for > timestamp formatting, via a default-on feature flag. When this code > was initially added to `tracing-subscriber`, the `time` crate did not > have support for the timestamp formatting options we needed. > > Unfortunately, the `chrono` crate's maintenance status is now in > question (see tokio-rs#1598). Furthermore, `chrono` depends on version 0.1 of > the `time` crate, which contains a security vulnerability > (https://rustsec.org/advisories/RUSTSEC-2020-0071.html). This > vulnerability is fixed in more recent releases of `time`, but `chrono` > still uses v0.1. I've replaced chrono with time 0.3. Unfortunately, some of chrono's builders for DateTimes are not present in `time`, which required the usage of `macro_rules!` macros to construct some of the hard-coded times. I also took the opportunity to tidy some of the tests and change the internal representation of `Rotation::NEVER` from year 9,999 to an `Option::None`. This branch changes `tracing-appender`'s MSRV from Rust 1.42 to Rust 1.51, the MSRV for the `time` crate when certain required feature flags are enabled. This does *not* effect the MSRV for other crates in this repository.
kaffarell
pushed a commit
to kaffarell/tracing
that referenced
this pull request
May 22, 2024
# 0.2.0 (October 22, 2021) This breaking change release adds support for the new v0.3.x series of `tracing-subscriber`. In addition, it resolves the security advisory for the `chrono` crate, [RUSTSEC-2020-0159]. This release increases the minimum supported Rust version (MSRV) to 1.51.0. ### Breaking Changes - Updated `tracing-subscriber` to v0.3.x ([tokio-rs#1677]) - Changed `NonBlocking::error_counter` to return an `ErrorCounter` type, rather than an `Arc<AtomicU64>` ([tokio-rs#1675]) ### Changed - Updated `tracing-subscriber` to v0.3.x ([tokio-rs#1677]) ### Fixed - **non-blocking**: Fixed compilation on 32-bit targets ([tokio-rs#1675]) - **rolling**: Replaced `chrono` dependency with `time` to resolve [RUSTSEC-2020-0159] ([tokio-rs#1652]) - **rolling**: Fixed an issue where `RollingFileAppender` would fail to print errors that occurred while flushing a previous logfile ([tokio-rs#1604]) Thanks to new contributors @dzvon and @zvkemp for contributing to this release! [RUSTSEC-2020-0159]: https://rustsec.org/advisories/RUSTSEC-2020-0159.html [tokio-rs#1677]: tokio-rs#1677 [tokio-rs#1675]: tokio-rs#1675 [tokio-rs#1652]: tokio-rs#1675 [tokio-rs#1604]: tokio-rs#1604
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
This PR continues the work started in #1646 to replace
chronowithtime. I'll refer to @hawkw's motivation:Solution
I've replaced chrono with time 0.3. Unfortunately, some of chrono's builders for DateTimes are not present in
time, which required the usage ofmacro_rules!macros to construct some of the hard-coded times. I also took the opportunity to tidy some of the tests and change the internal representation ofRotation::NEVERfrom year 9,999 to anOption::None.