New version (0.3.48) makes my project stop compiling

@jhpratt

Do not make "me too" comments. They add nothing of value and will only mean it takes longer for me to release a patch, as it's more I have to read. I am aware of the issue and the downstream breakage. A patch will be issued as soon as I am able.

Original issue follows.

Since updating the time crate from 0.3.47 to 0.3.48, my crate stop compiling with the following error message:

error[E0119]: conflicting implementations of trait `From<format_description::parse::format_item::HourBase>` for type `<format_description::parse::format_item::HourBase as format_description::parse::format_item::ModifierValue>::Type`
   --> .../tracing-subscriber-0.3.23/src/filter/env/mod.rs:759:1
    |
759 | / impl<S> From<S> for EnvFilter
760 | | where
761 | |     S: AsRef<str>,
    | |__________________^
    |
    = note: conflicting implementation in crate `time`:
            - impl From<format_description::parse::format_item::HourBase> for <format_description::parse::format_item::HourBase as format_description::parse::format_item::ModifierValue>::Type;
    = note: upstream crates may add a new impl of trait `core::convert::AsRef<str>` for type `time::format_description::parse::format_item::HourBase` in future versions

Not sure if it is the time crate responsibility or tracing_subscriber 🙈

I'm not sure what's going on. HourBase is a private type. May be a compiler bug?

Tested with cargo v1.90.0, nightly 1.98.0 (2026-06-11) and nightly 1.96.0 ( 2026-03-19)

Workaround

As mentioned in the thread, in your Cargo.toml, pin the time dependency:

-time = "0.3.47"
+time = "=0.3.47"

If time is a transitive dependency, then add the + line to your Cargo.toml. It's recommended to revert to unpinned dependency once the fix is in.

Please don't do this if your crate is a library upon which 3rd parties rely (🙏). It will likely result in duplicate time deps, and further compilation issues caused by incompatible same-crate types.

I have yanked v0.3.48. I want to be crystal clear that it will not be released as v0.4.0. A solution will be found and be re-released as v0.3.49.

Same issue with different toolchain:

rustup --version
rustup 1.29.0 (28d1352db 2026-03-05)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: the currently active `rustc` version is `rustc 1.96.0 (ac68faa20 2026-05-25)`

Workaround:

cargo update -p time --precise 0.3.47

fix(ci): pin broken upstream transitive releases

Is there a temporary fix?

As far as I can tell, it's impossible to pin versions of indirect dependencies using Cargo.

As far as I can tell, it's impossible to pin versions of indirect dependencies using Cargo.

Temporarily make it into a direct dependency and then you'll be able to pin it.

Is there a temporary fix?

As far as I can tell, it's impossible to pin versions of indirect dependencies using Cargo.

Pin the version with:

cargo update -p time --precise 0.3.47

But be careful with simple cargo update, I'll be the latest again.

check my pr https://github.com/time-rs/time/pull/784 i had fixed this.

Pin time to 0.3.47 to dodge the 0.3.48 coherence regression

This also broke the cookie crate: rwf2/cookie-rs#251

IMO, the issue is in the downstream crates implementing generic From conversions. These are are always footguns due to Rust's model. tracing_subscriber should implement From<&str> instead of From<S>. cookie should implement From<Option<OffsetDateTime>> instead of From<T>, and so on.

Anything made in this crate will be just workarounds. The crates with generic conversions should fix their code and get rid of these conversions.

@demurgos

@demurgos That's fair, but I also think this release of time should have had a minor version bump (0.4.0 instead of 0.3.48) to avoid breakage for a lot of projects that employ the "best practice" of relying on Cargo's freewheeling automatic upgrades. (By the way, I'm sure it wasn't intentional! Mistakes happen.)

Ah, I see. I thought having it in Cargo.toml was sufficient. I'll give that a shot.

Ah, I see. I thought having it in Cargo.toml was sufficient. I'll give that a shot.

[package]
name = "small_toy"
version = "0.1.1"
edition = "2024"
rust-version = "1.89"
readme = "./README.md"

[dependencies]
anyhow = "1"
figment = { version = "0.10", features = ["env", "toml"] }
jsonwebtoken = {version = "10", features = ["rust_crypto"]}
rust-embed = "8"
salvo = {version = "0.84", features = ["anyhow", "cookie", "cors", "jwt-auth", "oapi", "serve-static", "rustls", "logging", "test"]}
serde = "1"
thiserror = "2"
time = "0.3"
tokio = {version = "1", features = ["full"]}
tracing = "0.1"
validator = {version = "0.20", features = ["derive"]}
ulid = "1"
argon2 = "0.5"
cookie = "0.18"
dotenvy = "0.15"
tracing-appender ="0.2"
tracing-subscriber = {version = "0.3", features = ["std", "fmt", "env-filter", "tracing-log", "time", "local-time", "json"]}
sqlx = { version = "0.8", features = ["runtime-tokio", "macros", "sqlite"]}
rinja = "0.3"

Here is fairly small repo reproducing the problem: https://github.com/demurgos/time-783

I created a minimize branch where I'm working on providing the smallest code snippet triggering this problem. Right now (demurgos/time-783@8cbb166) I was able to include the relevant code from aws-smithy-types and time into the repo so everything is self-contained to trigger the issue.

From the previous self-contained reproduction, I minimized it to only two single-file crates exhibiting the issue. Still on my minimize branch, at commit demurgos/time-783@1234eff.

./aws-smithy-types/src/lib.rs:

pub mod timeout {
    pub use time::OffsetDateTime;

    enum CanDisable<T> {
        Set(T),
    }

    impl<T> From<T> for CanDisable<T> {
        fn from(value: T) -> Self {
            Self::Set(value)
        }
    }
}

./time/src/lib.rs:

pub struct OffsetDateTime;

pub mod format_description {
    pub mod parse {
        pub mod format_item {
            trait ModifierValue {
                type Type;
            }

            #[derive(Default, Clone, Copy)]
            enum HourBase {
                #[allow(unused)]
                Twelve,
                #[default]
                TwentyFour,
            }
            impl ModifierValue for HourBase {
                type Type = bool;
            }
            impl From<HourBase> for <HourBase as ModifierValue>::Type {
                fn from(modifier: HourBase) -> Self {
                    match modifier {
                        HourBase::Twelve => true,
                        HourBase::TwentyFour => false,
                    }
                }
            }
        }
    }
}

Running cargo check inside ./aws-smithy-types produces:

$ cargo +stable check
    Checking aws-smithy-types v1.4.9 (/data/projects/various/time-783/aws-smithy-types)
error[E0119]: conflicting implementations of trait `From<format_item::HourBase>` for type `<format_item::HourBase as format_item::ModifierValue>::Type`
 --> src/lib.rs:8:5
  |
8 |     impl<T> From<T> for CanDisable<T> {
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: conflicting implementation in crate `time`:
          - impl From<format_item::HourBase> for <format_item::HourBase as format_item::ModifierValue>::Type;

For more information about this error, try `rustc --explain E0119`.
error: could not compile `aws-smithy-types` (lib) due to 1 previous error

It was identified as a Rustc bug: rust-lang/rust#85898. see in the PR thread: #786 (comment)

fix: pin time to 0.3.47 to avoid E0119 regression in time 0.3.48 (tim…

Update deps except for time

Patch is on main and will be released shortly.

@jhpratt

Many thanks to @jhpratt for the investigation and quick response. Yesterday was stressful!

CI is green and it has now been released. Hopefully no more issues 🤞

Use READ COMMITTED isolation for migration backfill queries (#4495)

fix(deps): relax time bound to 0.3.55 (coherence bug fixed upstream)

chore(deps): unpin time and bump to 0.3.55 (#1220)

Navigation Menu

Repository navigation

New version (0.3.48) makes my project stop compiling #783

Workaround

33 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

New version (0.3.48) makes my project stop compiling #783

Description

Workaround

Activity

AntoineSebert commented on Jun 12, 2026

krisztianfekete commented on Jun 12, 2026

yossy4411 commented on Jun 12, 2026

alienscience commented on Jun 12, 2026

tliron commented on Jun 12, 2026

paolobarbolini commented on Jun 12, 2026

neunzehn86 commented on Jun 12, 2026

xlfish233 commented on Jun 12, 2026

yeoleobun commented on Jun 12, 2026

jperkin commented on Jun 12, 2026

longzou commented on Jun 12, 2026

demurgos commented on Jun 12, 2026

tliron commented on Jun 12, 2026

33 remaining items

jhpratt commented on Jun 13, 2026

xlfish233 commented on Jun 13, 2026

demurgos commented on Jun 13, 2026

demurgos commented on Jun 13, 2026

demurgos commented on Jun 13, 2026

demurgos commented on Jun 13, 2026

jhpratt commented on Jun 13, 2026

tliron commented on Jun 13, 2026

jhpratt commented on Jun 13, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions