subscriber: update time crate to 0.3.18 #2550

keepsimple1 · 2023-04-07T17:36:22Z

Motivation

As I asked earlier in discussions, I'm trying to use LocalTime in tracing-subscriber::fmt, i.e. something like this:

tracing_subscriber::fmt()
        .with_timer(tracing_subscriber::fmt::time::LocalTime::rfc_3339())

However, with the time crate 0.3.2, I need to build with --cfg unsound_local_offset, which is not desirable. In fact, time crate has removed this requirement since v0.3.18. Hence I propose to update time crate version in this branch.

Solution

Update time crate to version 0.3.18. I tried locally to use LocalTime after updating, there is no problem without --cfg unsound_local_offset.

hawkw

Thanks for the PR, I'm happy to increase the minimum time version.

There are notes in the docs here

tracing/tracing-subscriber/src/fmt/time/time_crate.rs

Lines 9 to 20 in b28c935

    
           /// <div class="example-wrap" style="display:inline-block"> 
        
           /// <pre class="compile_fail" style="white-space:normal;font:inherit;"> 
        
           ///     <strong>Warning</strong>: The <a href = "https://docs.rs/time/0.3/time/"><code>time</code> 
        
           ///     crate</a> must be compiled with <code>--cfg unsound_local_offset</code> in order to use 
        
           ///     local timestamps. When this cfg is not enabled, local timestamps cannot be recorded, and 
        
           ///     events will be logged without timestamps. 
        
           /// 
        
           ///    Alternatively, [`OffsetTime`] can log with a local offset if it is initialized early. 
        
           /// 
        
           ///    See the <a href="https://docs.rs/time/0.3.4/time/#feature-flags"><code>time</code> 
        
           ///    documentation</a> for more details. 
        
           /// </pre></div>

and here

tracing/tracing-subscriber/src/fmt/time/time_crate.rs

Lines 99 to 110 in b28c935

    
           /// <div class="example-wrap" style="display:inline-block"> 
        
           /// <pre class="compile_fail" style="white-space:normal;font:inherit;"> 
        
           ///     <strong>Warning</strong>: The <a href = "https://docs.rs/time/0.3/time/"> 
        
           ///     <code>time</code> crate</a> must be compiled with <code>--cfg 
        
           ///     unsound_local_offset</code> in order to use local timestamps. When this 
        
           ///     cfg is not enabled, local timestamps cannot be recorded, and 
        
           ///     events will be logged without timestamps. 
        
           /// 
        
           ///    See the <a href="https://docs.rs/time/0.3.4/time/#feature-flags"> 
        
           ///    <code>time</code> documentation</a> for more details. 
        
           /// </pre></div> 
        
           ///

discussing the unsound_local_offset cfg. If we're going to upgrade to a version of time where this is no longer required, we should also remove these notes from the documentation, so that users don't think they still need to enable that flag.

hawkw

looks good to me, thanks!

keepsimple1 · 2023-04-07T21:29:36Z

Thanks for reviewing and approving! There are some failures in CI. I'm not sure if they are related to this change (my guess is not, except the MSRV failures). Should I debug these CI errors?

hawkw · 2023-04-07T22:39:46Z

Thanks for reviewing and approving! There are some failures in CI. I'm not sure if they are related to this change (my guess is not, except the MSRV failures). Should I debug these CI errors?

It looks like a majority of the failing checks aren't related to this change. I you have the time to dig into them, that would be appreciated, but let's try and land any changes that fix stuff unrelated to this change in separate PRs please?

keepsimple1 · 2023-04-08T18:03:27Z

It looks like a majority of the failing checks aren't related to this change. I you have the time to dig into them, that would be appreciated, but let's try and land any changes that fix stuff unrelated to this change in separate PRs please?

Sure. I started with Clippy warnings: #2552 .

davidbarsky · 2023-04-10T12:40:11Z

Should this PR be pointing at the 0.1 branch? Has this been fixed on master?

keepsimple1 · 2023-04-10T16:14:15Z

Should this PR be pointing at the 0.1 branch? Has this been fixed on master?

It's the same on master. I submitted the change for 0.1.x as that's what I'm using ;-). I don't know what's the process of re-applying / cherrypicking a fix, but I can submit it again for master after this PR lands successfully.

hawkw · 2023-04-10T16:38:34Z

Should this PR be pointing at the 0.1 branch? Has this been fixed on master?

It's the same on master. I submitted the change for 0.1.x as that's what I'm using ;-). I don't know what's the process of re-applying / cherrypicking a fix, but I can submit it again for master after this PR lands successfully.

In general, we prefer to land new changes on master and then the maintainers will backport them to v0.1.x. If you have the time and energy to cherry-pick your own PR, though, that would be much appreciated!

davidbarsky · 2023-04-10T17:05:54Z

It's the same on master. I submitted the change for 0.1.x as that's what I'm using ;-). I don't know what's the process of re-applying / cherrypicking a fix, but I can submit it again for master after this PR lands successfully.

Yeah, what Eliza said. It's a lot easier for us to cherry-pick in a single direction. If you're using this, I'd be happy to prioritize a cherry-pick quickly.

I'd suggest using git cherry-pick -Xfind-renames $SOME_COMMIT—it handles renamed files quite nicely.

keepsimple1 · 2023-04-10T23:45:49Z

I have changed the base to master. I need to rebase the source branch and push again.

keepsimple1 · 2023-04-11T01:07:42Z

I've rebased the diff against master. Thanks for your suggestions.

Bump up the version of the `time` crate so that we don't need to build with `--cfg unsound_local_offset` for using `fmt::time::LocalTime`.

keepsimple1 · 2023-04-12T20:06:02Z

Rebased new changes again to the latest master. @davidbarsky @hawkw If there is something else I need to do, let me know. Thanks!

hawkw

looks good to me, thanks!

keepsimple1 · 2023-04-12T23:31:21Z

CI MSRV checked failed with rust 1.56.0. I think it's because time crate 0.3.18 specified rust-version = "1.62.0".

I guess we can't update time crate to 0.3.18 until CI moves to later Rust versions? Any plans to bump up Rust version for CI?

hawkw · 2023-04-13T21:57:26Z

CI MSRV checked failed with rust 1.56.0. I think it's because time crate 0.3.18 specified rust-version = "1.62.0".

I guess we can't update time crate to 0.3.18 until CI moves to later Rust versions? Any plans to bump up Rust version for CI?

Whoops, I didn't see this comment when this PR was merged. That's unfortunate, I think we may have to revert this change to maintain our current MSRV policy. However, if we go back to specifying a more permissive dependency on time that allows but does not require v0.3.18, users on Rust 1.62+ can explicitly specify time v0.3.18 in their dependencies to avoid having to use --cfg unsound_local_offset. We can document that if you specify time v0.3.18+ in your Cargo.toml or Cargo.lock, you no longer need to use this flag.

This reverts commit 9744ec0. This change breaks MSRV compatibility, and was accidentally auto-merged due to what appears to be an issue with the CI configuration, which (apparently) doesn't require the MSRV minimal-versions check runs to complete before allowing a branch to merge. We'll have to solve the original issue here through documentation for now. See [this comment] for details. [this comment]: #2550 (comment)

keepsimple1 · 2023-04-13T23:00:29Z

Whoops, I didn't see this comment when this PR was merged. That's unfortunate, I think we may have to revert this change to maintain our current MSRV policy. However, if we go back to specifying a more permissive dependency on time that allows but does not require v0.3.18, users on Rust 1.62+ can explicitly specify time v0.3.18 in their dependencies to avoid having to use --cfg unsound_local_offset. We can document that if you specify time v0.3.18+ in your Cargo.toml or Cargo.lock, you no longer need to use this flag.

Did you mean we revert and add ~ :

[dependencies]
time = "~0.3.2"

and also document like you said?

(I never used ~, so not completely sure)

EDIT: well, even the original time = "0.3.2" allows using 0.3.18. So we probably only need to revert and add documentations?

This reverts commit 9744ec0. This change breaks MSRV compatibility, and was accidentally auto-merged due to what appears to be an issue with the CI configuration, which (apparently) doesn't require the MSRV minimal-versions check runs to complete before allowing a branch to merge. We'll have to solve the original issue here through documentation for now. See [this comment] for details. [this comment]: #2550 (comment)

keepsimple1 requested review from hawkw and a team as code owners April 7, 2023 17:36

hawkw requested changes Apr 7, 2023

View reviewed changes

hawkw approved these changes Apr 7, 2023

View reviewed changes

keepsimple1 changed the base branch from v0.1.x to master April 10, 2023 23:44

keepsimple1 requested review from yaahc, carllerche and davidbarsky as code owners April 10, 2023 23:44

keepsimple1 force-pushed the v0.1.x-time-update branch from e1e3627 to 61bf69e Compare April 10, 2023 23:57

subscriber: update time crate to 0.3.18

d1e5adf

Bump up the version of the `time` crate so that we don't need to build with `--cfg unsound_local_offset` for using `fmt::time::LocalTime`.

keepsimple1 force-pushed the v0.1.x-time-update branch from 61bf69e to d1e5adf Compare April 12, 2023 20:02

hawkw approved these changes Apr 12, 2023

View reviewed changes

hawkw enabled auto-merge (squash) April 12, 2023 21:06

Merge branch 'master' into v0.1.x-time-update

91cf34b

hawkw merged commit 9744ec0 into tokio-rs:master Apr 13, 2023

davidbarsky mentioned this pull request Sep 26, 2023

chore: backport roughly a year's worth of changes #2728

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

subscriber: update time crate to 0.3.18 #2550

subscriber: update time crate to 0.3.18 #2550

keepsimple1 commented Apr 7, 2023

hawkw left a comment

hawkw left a comment

keepsimple1 commented Apr 7, 2023

hawkw commented Apr 7, 2023

keepsimple1 commented Apr 8, 2023

davidbarsky commented Apr 10, 2023

keepsimple1 commented Apr 10, 2023

hawkw commented Apr 10, 2023

davidbarsky commented Apr 10, 2023

keepsimple1 commented Apr 10, 2023

keepsimple1 commented Apr 11, 2023

keepsimple1 commented Apr 12, 2023

hawkw left a comment

keepsimple1 commented Apr 12, 2023

hawkw commented Apr 13, 2023

keepsimple1 commented Apr 13, 2023 •

edited

Loading

	/// <div class="example-wrap" style="display:inline-block">
	/// <pre class="compile_fail" style="white-space:normal;font:inherit;">
	/// <strong>Warning</strong>: The <a href = "https://docs.rs/time/0.3/time/"><code>time</code>
	/// crate</a> must be compiled with <code>--cfg unsound_local_offset</code> in order to use
	/// local timestamps. When this cfg is not enabled, local timestamps cannot be recorded, and
	/// events will be logged without timestamps.
	///
	/// Alternatively, [`OffsetTime`] can log with a local offset if it is initialized early.
	///
	/// See the <a href="https://docs.rs/time/0.3.4/time/#feature-flags"><code>time</code>
	/// documentation</a> for more details.
	/// </pre></div>

subscriber: update time crate to 0.3.18 #2550

subscriber: update time crate to 0.3.18 #2550

Conversation

keepsimple1 commented Apr 7, 2023

Motivation

Solution

hawkw left a comment

Choose a reason for hiding this comment

hawkw left a comment

Choose a reason for hiding this comment

keepsimple1 commented Apr 7, 2023

hawkw commented Apr 7, 2023

keepsimple1 commented Apr 8, 2023

davidbarsky commented Apr 10, 2023

keepsimple1 commented Apr 10, 2023

hawkw commented Apr 10, 2023

davidbarsky commented Apr 10, 2023

keepsimple1 commented Apr 10, 2023

keepsimple1 commented Apr 11, 2023

keepsimple1 commented Apr 12, 2023

hawkw left a comment

Choose a reason for hiding this comment

keepsimple1 commented Apr 12, 2023

hawkw commented Apr 13, 2023

keepsimple1 commented Apr 13, 2023 • edited Loading

keepsimple1 commented Apr 13, 2023 •

edited

Loading