Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Completely migrate to core::time::Duration #497

Open
Plecra opened this issue Nov 6, 2020 · 6 comments
Open

Completely migrate to core::time::Duration #497

Plecra opened this issue Nov 6, 2020 · 6 comments

Comments

@Plecra
Copy link

Plecra commented Nov 6, 2020

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
Copy link

gerob311 commented Apr 23, 2021

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
Copy link
Collaborator

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.

@pitdicker pitdicker closed this as not planned Won't fix, can't repro, duplicate, stale Feb 5, 2024
@djc
Copy link
Member

djc commented Feb 5, 2024

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
Copy link
Collaborator

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

@djc
Copy link
Member

djc commented Feb 5, 2024

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.

@pitdicker pitdicker reopened this Feb 5, 2024
@djc
Copy link
Member

djc commented Feb 5, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants