Consider reintroducing `unsound_local_offset`

[davidbarsky]

Hi! I know that unsound_local_offset was never officially supported, but would you be willing to (briefly) re-introduce support for the unsound_local_offset flag? While most users of tracing-subscriber don't use the local time feature, a lot of people at my employer do make use of it, and migrating people to include time in the dependencies to call time::util::local_offset::set_soundness instead will be a bit painful.

(For context, there's about several hundred Rust targets that use this feature that is set globally once, and while we'd like to move over to the new API, we don't yet have a mechanism to do a monorepo-wide refactor like this yet.)

[jhpratt]

No, it will not be reintroduced.

tracing-subscriber should have never encouraged users to set the flag. It was outright broken on at least one occasion because it was never tested (as explicitly stated). Using the flag should have been an absolute last resort when all other options were exhausted, not something done on a routine basis. Nor should set_soundness ever be used by a library seen by others; this is stated in the safety documentation. The previous behavior was equivalent to using tree shears when a surgical knife was needed. We've moved away from using the shears, but we're still using ordinary scissors. The surgical knife remains elusive due to a design decision that was made nearly 20 years before I was even born. Until we get that knife, the current behavior is about as good as it can be. unsound_local_offset was functionally equivalent to calling set_soundness(Unsound) right at the start of your program. It was almost always a horrendous idea.

Forgive me for being blunt, but I'm working with limited resources and have, on multiple occasions, put out calls for funding. If I had more time to dedicate to this crate, I probably could have came up with a better solution/API, done more research into how various operating systems handle environment variables to provide better mitigations, provided a transition period with guidance, etc. If this crate is truly relied upon by your employer in such a capacity that you felt the need to create an issue, then some level of funding would not be unwise for your benefit. It's a drop in the bucket compared the monumental market cap that they have, but would provide a level of assurance that I have the necessary resources to make an informed, well-planned, deliberate decision.

[davidbarsky]

tracing-subscriber should have never encouraged users to set the flag. It was outright broken on at least one occasion because it was never tested (as explicitly stated).

I'm not sure if tracing-subscriber ever really did encourage people to set this flag (my feeling that that our documentation is relatively neutral on this point and defers to time's), but I suppose intent doesn't really matter here.

Using the flag should have been an absolute last resort when all other options were exhausted, not something done on a routine basis.

I agree with you here—I spent a week trying to find an alternative before settling on the approach I did. I recognize that I elided this point in the original and most users of tracing-subscriber don't have this issue, but I've ended up in the unfortunate situation where it was the exception to the horrendous idea.

Forgive me for being blunt, but I'm working with limited resources and have, on multiple occasions, put out calls for funding. If I had more time to dedicate to this crate, I probably could have came up with a better solution/API, done more research into how various operating systems handle environment variables to provide better mitigations, provided a transition period with guidance, etc. If this crate is truly relied upon by your employer in such a capacity that you felt the need to create an issue, then some level of funding would not be unwise for your benefit.

You're certainly not wrong!