Why the breaking change from chrono to jiff just like that with no interop?

[tgrushka]

It's really frustrating to have found that chrono is no longer supported, because "it's old"?

Why fix what isn't broken? Never heard of this jiff crate before, but I see it has existed for less than 2 years. That's hardly "stable" for a longstanding project like this crate.

It also breaks the backwards compatibility principle. While this is not Rust core, it still is a major, major breaking change for anyone using this library.

Now, we have to find every instance of the usage of DateTime<Utc> in our codebase and manually convert it, becase jiff provides zero interop with chrono.

jiff also supports a much smaller timespace than chrono and therefore conversions from DateTime<Utc> to jiff are not Infallible and actually one has to do this manually with helper functions.

In #163 someone just thought they would be so helpful by suggesting this feature, and to their credit, they asked it to be feature-gated.

Instead, someone ripped out all the chrono code and replaced it with jiff without considering implications to downstream crate authors with real projects.

This is frustrating. It feels like no consideration was given to all the individual work users of this crate would have to do to make it work with jiff instead of chrono.

Are we expected to just convert our projects over to jiff, a completely new (< 2 years old) crate that is not really battle tested? It is certainly popular, with almost a "move fast and break things" mentality. I would much rather have the option to move to it if I so desire.

Why wasn't it put in with a feature gate as #163 suggested?

And the Time wrapper was already annoying, but understandably necessary, but why weren't From<DateTime<Utc>> and Copy ever implemented for it? It was already a tiny bit annoying to have to deal with this extra wrapper, but now, frankly Time in this crate is totally unusable without global helper functions to convert to/from chrono or time.

I was going to make a crate, but then hit the wall again that I cannot implement any conversions between two third-party crates. This seems like "gatekeeping" to me, and it's a Rust maintainers' decision, but oh well. It seems silly that there is absolutely no conversion for this.

I'm not going to rip apart my entire project and replace every instance of chrono with jiff just because its author "encourages me to jump into the pit of success." This is hardly what I had in mind for success. While it may be the best thing since sliced bread to some, it's not like a crate refactor with #[deprecated] notices for which I can just use the analyzer to fix it. This is a major, major breaking change that really should have been better thought out, and I'm sorry for everyone who has had to suffer for this. I wonder if this post really comes as a major surprise to the author. I don't know, but until Rust has a std::datetime, I really don't think jiff should be forced so suddenly and irreversibly on the community like this.

[Arnavion]

It also breaks the backwards compatibility principle.

The change was released in a semver major release. Semver major releases are allowed to be backward-incompatible.

---

jiff provides zero interop with chrono.

I assume based on what you wrote later that you're already aware of how to do the conversion, but for the sake of others, it's jiff::Timestamp -> as_second(), subsec_nanosecond() -> chrono::DateTime::from_timestamp() -> chrono::DateTime<chrono::Utc>, and similar for the other way around.

---

Why wasn't it put in with a feature gate as #163 suggested?

Features are unified over the whole dep tree, so if one crate depends on k8s-openapi and assumes chrono is being used, and another crate depends on k8s-openapi and assumes jiff is being used, one of them will cause the other to fail to compile. I didn't say anything about it in the original issue because I didn't expect anyone to actually impl it as feature-gated, only as a full replacement, which is exactly what happened.

---

but why weren't From<DateTime<Utc>> and Copy ever implemented for it?

Things that users want get implemented when they express those wants. Neither was impl'd originally. Then a user asked for From<_> to be impl'd, so it was done.

---

I was going to make a crate, but then hit the wall again that I cannot implement any conversions between two third-party crates.

You cannot do it by impl'ing From<> or Into<> because of the orhpan rule, yes. You can either make free fns or your own conversion traits.

---

This seems like "gatekeeping" to me, and it's a Rust maintainers' decision, but oh well. It seems silly that there is absolutely no conversion for this.

You would need to say express this in the chrono and jiff crates' trackers, not here.

---

I wonder if this post really comes as a major surprise to the author.

It does not come as a surprise in the sense that I expected it would be a simple change for some users (who don't care about the Time fields) and a disruptive change for others (who do).

---

Why fix what isn't broken?

I really don't think jiff should be forced so suddenly and irreversibly on the community like this.

I have thus recorded one vote for reverting to chrono. We can use this issue to track how many others prefer one vs the other.

[drmorr0]

Second the vote for reverting to chrono, I just came across this when I tried to update. All my other code uses chrono extensively. I'm keeping the old version pinned for now, but this is going to be a big pain to deal with if/when I need to support more recent Kubernetes versions.

[relrod]

Hi @Arnavion, thanks for k8s-openapi!

I'm throwing in a vote that I also think this should be feature-gated.

I don't particularly buy:

if one crate depends on k8s-openapi and assumes chrono is being used, and another crate depends on k8s-openapi and assumes jiff is being used, one of them will cause the other to fail to compile.

Yes, it is true that the build will fail, but then likely the solution is that the other conflicting library should also make jiff a feature flag and I would then raise an issue/PR on that other library.

It is similar to how you can use ring or aws-lc-rs with most any library that does TLS. Yes, as a consumer of the libraries, you want to standardize on one, but you are not forced into one or the other, you are just forced to make a choice and be consistent and I think that is the request here. We aren't saying "revert and never use jiff. Keep it around if you prefer it, but allow people to select the ecosystem they prefer - that is the request.

Lastly,

The change was released in a semver major release. Semver major releases are allowed to be backward-incompatible.

Can you clarify this? I think I've misunderstood something. As far as I know, the major part of a semver version is the "x" in "x.y.z", and "x" has remained 0 here, meaning the change came in a minor version. Do I have something wrong?

Thanks again for your work on the library!

[Arnavion]

It is similar to how you can use ring or aws-lc-rs with most any library that does TLS. [...] you are just forced to make a choice and be consistent

You are not forced to do that. Those features of rustls are not exclusive. One part of your dep tree that wants to use aws_lc_rs::default_provider() specifically can enable the aws-lc-rc feature, and another part of your dep tree that wants to use ring::default_provider() specifically can enable the ring feature, and both will work fine.

But jiff vs chrono in k8s-openapi would be exclusive. k8s_openapi::Time can only wrap one of them; it can't wrap both. And whatever it wraps is public API, so one part of the dep tree can expect it to be jiff::Timestamp and enable the jiff feature, whereas another part of the dep tree can expect it to be chrono::DateTime and will fail to compile.

---

We aren't saying "revert and never use jiff. Keep it around if you prefer it, but allow people to select the ecosystem they prefer - that is the request.

Obviously you're not saying that. As users you only care about the one impl you want to use. The responsibility of maintaining both impls is not yours. So it's a question about balancing your one-time work of switching from chrono to jiff, multiplied by the number of you's, vs my perpetual work of maintaining two impls for dubious benefit.

---

Can you clarify this? I think I've misunderstood something. As far as I know, the major part of a semver version is the "x" in "x.y.z", and "x" has remained 0 here, meaning the change came in a minor version. Do I have something wrong?

The Rust ecosystem, and cargo specifically, treat 0.x.y as having major x and minor y when evaluating semver compatibility. Most of the crates.io ecosystem is 0.* and would be unusable without this special casing.

[ngergs]

fyi chrono is soft-deprecated and e.g. won't get timezone changes anymore. jiff is recommended there as a replacement.