-
-
Notifications
You must be signed in to change notification settings - Fork 38
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
Timestamp::saturating_add misbehaves if the span contains calendar units #36
Comments
Thank you for catching this. This was a bad oversight on my part. I think I had written the saturating method routine before I smoothed out the error cases for checked arithmetic. This will indeed mean that This also motivates #21, because with an "absolute" duration, we can provide infallible saturating arithmetic on |
The saturating methods *should* return an error. But I goofed on the API. So at this point, our two choices are: leave it as-is, which produces completely incorrect results when there are non-zero units of days or greater, or panic when it occurs. I think a panic is better. In Jiff 0.2, these APIs will be made fallible. And hopefully by then we'll have truly infallible APIs that accept an "absolute" duration. Partially addresses #36
The saturating methods *should* return an error. But I goofed on the API. So at this point, our two choices are: leave it as-is, which produces completely incorrect results when there are non-zero units of days or greater, or panic when it occurs. I think a panic is better. In Jiff 0.2, these APIs will be made fallible. And hopefully by then we'll have truly infallible APIs that accept an "absolute" duration. Partially addresses #36
The saturating methods *should* return an error. But I goofed on the API. So at this point, our two choices are: leave it as-is, which produces completely incorrect results when there are non-zero units of days or greater, or panic when it occurs. I think a panic is better. In Jiff 0.2, these APIs will be made fallible. And hopefully by then we'll have truly infallible APIs that accept an "absolute" duration. Partially addresses #36
Expectation: Error, panic or some other indication that addition failed.
Actual result:
9999-12-30T22:00:00.999999999Z
The text was updated successfully, but these errors were encountered: