Completely migrate to core::time::Duration

[Plecra]

This would be ideal for usability of the Duration type, and promote more compatibility with other crates. It's been mentioned a few times over the years, and was a goal back in 2016.

As back then, this would be a major breaking change and would need to be prepared for 0.5. core::time::Duration also doesn't have some of the utility methods like oldtime::Duration::days, which we might want to replace in some fashion.

The main issue is time::Duration's lack of support for negative durations. This will force us to change a few APIs that return possibly-negative values. It'd be good to review which APIs will change before working on the implementation.

[gerob311]

Hey, I'm pretty new to Rust and chrono, but so far, I'm not convinced that completely replacing chrono::Duration with core::time::Duration is a good idea, because of the lack of support for negative durations that you mentioned.

How would you represent negative durations under this proposal?

[pitdicker]

I don't think a complete migration to core::time::Duration is a goal anymore. It is a limited type, mostly intended for interfacing with system API's.

There are advantages to having a more fully featured type for a date and time library. Allowing negative values is one. Other are that we can implement (de)serialization, formatting and parsing, and generally just have control over its implementation and API.

[djc]

Note that #1229 already added a bunch of support for using core::time::Duration with chrono's types, and rust-lang/rust#120301 proposed adding a few more utility methods to core::time::Duration.

[pitdicker]

Interesting, I didn't know you were working on that in the standard library.

[djc]

Well, this is motivated by my day job work sharing me and my notions of not wanting to use chrono::Duration for anything ideally.

So in my mind, our current direction is aligned with this issue.

[djc]

To be clear, I think there are some places in the API where we might still have a need for something like chrono's Duration (called TimeDelta since #1406), but I think that use is probably limited to output types in subtraction/difference calculations, where an unsigned type can't represent the range of values required and Option or Result-wrapping the outcome might impair the UX. For input types, I think the unsigned core::time::Duration is sufficient.