build(deps): pin time to 0.3.47 to avoid aws-smithy-types E0119

[brendanclement]

Context

time 0.3.48 (published 2026-06-12) added a From impl on an associated type that rustc's coherence checker treats as conflicting with any crate carrying a generic blanket From<T> impl. For us that is aws-smithy-types 1.4.5's impl<T> From<T> for CanDisable<T>, which fails to compile with E0119:

error[E0119]: conflicting implementations of trait `From<...HourBase>`
  --> aws-smithy-types-1.4.5/src/timeout.rs:49
49 | impl<T> From<T> for CanDisable<T> {
  = note: conflicting implementation in crate `time`

This is an ecosystem-wide break tracked upstream in time-rs/time#783. The maintainer has acknowledged it and a patch is pending.

For lance it takes down every Rust and Python build job. main has been red since the first CI run after the upstream release, with no code change in between: CI re-resolved the newly published time at build time, and the
subsequent beta release baked 0.3.48 into the committed lockfiles. It blocks all open PRs, not just one (#7254 rebases on top once this lands).

Change

Pin time to the last good release, 0.3.47, via cargo update -p time --precise 0.3.47 (the workaround recommended in time-rs/time#783). Applied to both lockfiles:

• Cargo.lock (root workspace)
• python/Cargo.lock (the python/ crate is excluded from the root workspace
  and carries its own lock, so the Python wheel and lint jobs need the pin too)

Lockfile only, no manifest or source change. Downgrades time (0.3.48 to 0.3.47), time-core, and time-macros. Nothing requires >= 0.3.48 (it is hours old), so the pin is safe.

Test plan

• cargo check -p aws-smithy-types --locked compiles clean in both the root and python/ workspaces (was E0119).
• Locked CI jobs are green again (clippy, MSRV, rustdoc, and the rest).

Note on build-no-lock

build-no-lock stays red by design and is non-blocking. It removes Cargo.lock and re-resolves against the latest crates, so it re-pulls the broken time 0.3.48 regardless of this pin. It is the canary for exactly this
kind of upstream break, and main currently merges with it red (#7234 merged today with it failing).

Follow-up

Remove the pin once upstream resolves the conflict, tracked in time-rs/time#783:

• the fix in fix: avoid associated type projection in modifier! From impl time-rs/time#784 ships (expected as time 0.3.49), bump to it, or
• 0.3.48 is yanked (requested in the issue), in which case a fresh resolve returns to 0.3.47 on its own and build-no-lock self-heals.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[wjones127]

I think we can close this as the upstream issue has been addressed.