time

To clarify this a bit: 1. The widely used Time crate had some code which converted to an unspecified type. The code then converted this again in a following line. Because there was only a single possible (identity) conversion, this code was a noop. Regardless this was fixed in time@0.1.35 (released in April 9, 2024). [1] 2. Rust 1.80 (released July 27, 2024) introduced a new trait implementations that made the second conversion now cause the first conversions to have two possible inferences. [2] 3. Rust packages that upgraded the compiler to 1.80.0, but used a version of the time crate prior to 0.1.35 fail to build the time dependency. This is mitigated by the fact that 0.1.35 is a semver compatible update, which just requires running cargo update to use. [1]: https://github.com/time-rs/time/pull/671 [2]: https://blog.rust-lang.org/2024/0

> This PR seems relevant... It's not. The change doesn't have anything to do with the prelude. It was a new conversion was added, where existing code made an assumption that there was only one possible conversion that satisfied an inferred type. (In fact when that code was written it was superfluous as the conversion was actually converting from one type to the same type). That code was removed in https://github.com/time-rs/time/pull/671 The only code that is strongly broken by this is code that doesn't update its dependencies more regularly than its compiler... locking your deps but refusing to do so with your toolchain is just plain weird IMHO.

I was wondering why and it looks like a new trait implementation in std made a type placeholder ambiguous in older versions of time? time was caught in a crater run when a new trait implementation was added to the standard library. While it is a breaking change, it is considered acceptable breakage because the alternative is never adding any trait implementations or methods. https://github.com/time-rs/time/issues/681#issuecomment-2143...

So, one area in which Rust is okay with "breaking" source compatibility is if some inference gets confused, and you need to add a type annotation. This issue was discovered before the release, and a new version of time was released to fix it. cargo update -p time and you're done. This doesn't happen very often. It bit one of my projects too, and it took me longer to realize that it was a new version release that caused the problem than it did to fix the problem. It's been so long since something like this happened to me I cannot remember when it happened last. Here's the upstream issue, if you're curious https://github.com/time-rs/time/issues/693

The problem is that this effects higher languages too, because they often build on libc. And on some OSes, they don't have a choice, because the system call interface is unstable and/or undocumented). For example in rust, multiple time libraries were found to be unsound if `std::env::set_env` was ever called from a multi-threaded program. See: https://github.com/time-rs/time/issues/293 and https://github.com/chronotope/chrono/issues/499 https://github.com/rust-lang/rust/issues/27970 https://github.com/rust-lang/rust/issues/90308

That is a trade-off, as the team typically needs a common vision that might not be easy to distribute (or even extract out of your mind). I had a similar problem with Chrono [1], the most popular Rust date & time library at the moment (though now rivalled by time-rs [2] ;-), where I was struggling with personal issues and yet (thus?) unable to sufficiently materialize my vision. Eventually I gave up and passed a torch to other interested people, one of which is now the primary maintainer, but no major API design and stabilization that would lead to the 1.0 is not happening as far as I concern. [1] https://github.com/chronotope/chrono/ [2] https://github.com/time-rs/time