To expand on some of the things already said: This issue was caught during a crater run. An earlier version of time had (accidentally) an "identity" conversion

To expand on some of the things already said: This issue was caught during a crater run. An earlier version of time had (accidentally) an "identity" conversion (<T as Into>::into(T)), which was caught by a blanket trait implementation. That call shouldn't have been in the library in the first place (it was speculated by its author that it was used in some transitory test in the past). Inference is brittle, there's no way around that. Adding a new trait impl can break down streams. The project makes an effort to avoid big blast radius when this happens, including backing off on the change and/or letting the ecosystem adapt before actually introducing the change. In this case there was a decision made to bite the bullet given that time would have a fix. Personally I would have preferred to delay the landing of the impl in order to add a migration lint for at least one release cycle. Today you can pin your rustc version to avoid these kind of surprises, but you shouldn't have to. I am personally concerned about being able to build random projects from today in 10 years, and I hope we can manage that. Looking at the root problem here, I'm gonna see if I can write a lint against the identity conversion impl in expressions to see how many more potential mines are in the ecosystem. If there aren't that many, we can enable that lint by default and prevent future occurrences of this. I would also like to extend the diagnostic people hit in this case to be more actionable (but end users wouldn't see that until 1.82 at the latest when compiling against an older time, it might be worth it for future users only). Completely freezing std to completely avoid these issues is not reasonable. End users can always smoke test against beta in order to get advance notice of these kind of issues. These kind of issues should be rare. If they are not, it's a fuck-up, and we'd love to see bug reports so that we can rework our release process accordingly.