Replacement of chrono with jiff -- concerns about process and impact

[tgrushka]

Hello everyone,

I’d like to open a discussion about the recent replacement of chrono with jiff in k8s-openapi and subsequently in kube-rs. This change was made without an RFC, community discussion, deprecation period, or migration path. I believe this raises important questions about project governance and user impact.

What happened?

• k8s-openapi replaced chrono with jiff based on a single suggestion citing “gaining traction” (#163), without a feature flag or deprecation period.
• kube-rs followed suit, citing “alignment,” but without clear technical justification or community input.

Why is this concerning?

1. Lack of community input – Rust crates, especially widely used ones, benefit from open discussion and consensus. This change was made unilaterally.
2. No migration path – Users now face breaking changes with no clear upgrade path, forcing immediate and potentially costly migrations.
3. Questionable technical justification – The cited performance difference (57 ns vs 158 ns) is negligible in real-world applications, especially compared to network and serialization overhead.
4. Ecosystem fragmentation – Many projects already use chrono with databases (e.g., sqlx, diesel) and other libraries. Forcing a switch adds friction and conversion overhead.
5. Long-term stability – jiff is relatively new (<2 years) and maintained by a single author in their spare time. What happens if it’s abandoned?

Technical concerns with jiff:

• The Error type is opaque and non-idiomatic (inner: Option<Arc<_>>), making error handling difficult.
• No Copy implementation for k8s-openapi::Time, despite jiff::Timestamp and DateTime<Utc> being Copy.
• No conversion traits to/from chrono or other time libraries, forcing lock-in.

What could have been done better?

• An RFC or discussion to evaluate the need and alternatives.
• A feature flag to allow gradual migration.
• Providing From/Into conversions between k8s_openapi::Time and chrono::DateTime<Utc> to avoid forcing a dependency switch.
• A clear deprecation period and migration guide.

Questions for maintainers:

1. What specific problems did chrono cause that jiff solves?
2. Was there consideration for providing conversions or feature-flagging to ease migration?
3. How will future breaking changes be handled to include community feedback?
4. Is there a plan to make k8s-openapi::Time Copy?
5. Could k8s-openapi abstract time types behind a trait to let users choose their preferred library?

Proposal:

• Consider re-adding chrono support behind a feature flag.
• Provide conversion traits between k8s_openapi::Time and major time libraries.
• Establish a policy for future breaking changes that includes community discussion and migration paths.

Rust’s strength is its community and ecosystem. Forcing a dependency switch without input or a migration path undermines that. Let’s work together to find a solution that respects users and maintains trust.

Thank you for considering this feedback.

[shanesveller]

This seems to relitigate #1924 , #1925 and Arnavion/k8s-openapi#163

For other visitors, it would be helpful and transparent to link to previous discussions that already occurred. Both crates' maintainers have already weighed in on an earlier form of this feedback.

[nightkr]

Yeah, we don't need a third discussion on the same topic. Closing this in favour of #1925.