No one uses jiff except k8s-openapi, and chrono is gone. Now suddenly we all have to because, "alignment"?

[tgrushka]

Current and expected behavior

Here are the reasons I think this is a bug:

1. k8s-openapi#163 was opened, with the request jiff replace chrono "behind a feature flag." An "unstable" feature flag + migration path, if deprecation of chrono was inevitable, would have been the correct way to do it, given that jiff is less than 2 years old.
2. chrono works fine. It wasn't broken. Why fix something that was not broken? Maybe minor edge cases? Maybe it's not maintained as much? I see the latest update to chrono crate was pretty recent. Granted it has issues but it's the most ubiquitous and supported currently. It worked perfectly. Never had a single issue with chrono in kube-rs. Hasn't anyone these days heard of "if it aint broke, don't fix it," or is that idea gone with the wind?
3. k8s-openapi author ripped out chrono and replaced it with jiff ... because, "Moms like you use jiff?" Did not use the feature flag as requested by the issue author.
4. kube-rs followed suit because, "alignment" and "dependency reduction"? So kube-rs is basically "hostage" to whatever k8s-openapi author decides to do, even though most of that codebase is generated?

Not saying jiff is a bad crate. Maybe it's great. Maybe it's much better than chrono. Not saying it isn't. I've never even seen or heard of it before, but boy is it suddenly popular! But it's modeled after JavaScript's new Temporal and has a much smaller "timespace" than chrono. Maybe because it's JavaScript compatible or something? Seems like a downgrade to me, maybe not. Maybe this will allow kube-rs to work well in WASM? I can see that, and I get it, if that's the case, you can write a WASM kube client, great.

But no discussion, no community feedback, no RFC, no #[deprecated] path, nothing.

Who else uses jiff besides k8s-openapi, now kube-rs, and "Moms like you"?

Is this really the way things are starting to be done in the Rust ecosystem now? Backwards compatibility no longer matters?

There are no From<Chrono<Utc>> impls so now we have to write a bunch of global helpers and remember to use those? Because of the orphan rule, we cannot write our own From<T> impls for this!!

This really imposes a lot of extra work on us, to wrap every single call from Time(now) to Time(convert_from_chrono_to_timestamp(now)). Easy in small codebase. Not so much in larger codebase.

Just not very Rusty. I'm not impressed with this "move fast and break things" decision without any community discussion over it. But alas, the decision has been made, right or wrong, so is it too late to fix this?

Possible solution

Push back on the k8s-openapi author to put a feature gate as requested.

Better yet, work with k8s-openapi to make a trait for which you can impl From in an infallible way (clamp to valid ranges if you have to) from any time crate, now that everyone and their brother is authoring them.

There are a number of better migration paths than the somewhat reckless one that was chosen.

Additional context

No response

Environment

Most applicable: I'm trying to upgrade to kube v3.0.0

kubectl version
Client Version: v1.33.4
Kustomize Version: v5.6.0
Server Version: v1.33.2+k3s1

Configuration and features

kube = { version = "3", features = ["derive", "runtime", "ws"] }
k8s-openapi = { version = "0.27", features = ["latest", "schemars"] }

YAML

No response

Affected crates

No response

Would you like to work on fixing this bug?

None

[clux]

tbf chrono had repeatedly given us issues in the past (broken things on patch releases, a cve for env usage, then disappearing for months before a fix propagated leaving cve issues on everyone, removed convenience behavior forcing us to re-implement basic functionality).

the reason there wasn't much discussion - and i did ask around - was that everyone i spoke to was was happy to get rid of it.
and from trying to convert (i.e. propagate the jiff change to my crates rather than deal with messy conversions) i found that my other codebases ended up easier also.

(specifically, my Time wrapping actually got easier because they now implement From. Arnavion/k8s-openapi#174 )

would a feature flag and deprecation path had been better, yes, if it was practical.
but it requires that people ask for it ahead of time.
complaints at this point is pointless. moved this to a discussion.

if it is truly that big of a pain, you can ask k8s-openapi directly? maybe if you are less sarcastic you will be successful.

[nightkr]

An "unstable" feature flag + migration path, if deprecation of chrono was inevitable, would have been the correct way to do it, given that jiff is less than 2 years old.

At least the current newtyping API wouldn't be able to be maintained like that, since you'd still have to decide on some canonical type for Time.0 (or remove it entirely).

A feature flag wouldn't help much here, since feature flags should only be for additive changes.

kube-rs followed suit because, "alignment" and "dependency reduction"? So kube-rs is basically "hostage" to whatever k8s-openapi author decides to do, even though most of that codebase is generated?

As things look today, yes. There'd be little point in keeping things different between the crates "just because".

"most of that codebase is generated" is also kind of a misnamer in these days of "AI" slopware. k8s-openapi maintains its code generator, and decides on the design tradeoffs of the generated code.

Who else uses jiff besides k8s-openapi, now kube-rs, and "Moms like you"?

https://crates.io/crates/jiff/reverse_dependencies