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

Remove check for DurationExceedsTimestamp #1403

Merged
merged 3 commits into from
Feb 7, 2024

Conversation

joroKr21
Copy link
Contributor

@joroKr21 joroKr21 commented Feb 2, 2024

This check is not necessary and prevented rounding and truncation from working correctly on timestamps close to the Unix epoch.

fixes #1375

Thanks for contributing to chrono!

If your feature is semver-compatible, please target the main branch;
for semver-incompatible changes, please target the 0.5.x branch.

Please consider adding a test to ensure your bug fix/feature will not break in the future.

Copy link

codecov bot commented Feb 2, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (ef9a4c9) 91.85% compared to head (377fe51) 91.86%.

❗ Current head 377fe51 differs from pull request most recent head ac28866. Consider uploading reports for the commit ac28866 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1403   +/-   ##
=======================================
  Coverage   91.85%   91.86%           
=======================================
  Files          38       38           
  Lines       17526    17531    +5     
=======================================
+ Hits        16098    16104    +6     
+ Misses       1428     1427    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@pitdicker
Copy link
Collaborator

Thank you @joroKr21. I'll have to think this through.

src/round.rs Show resolved Hide resolved
@@ -220,9 +217,6 @@ where
return Err(RoundingError::DurationExceedsLimit);
}
let stamp = naive.timestamp_nanos_opt().ok_or(RoundingError::TimestampExceedsLimit)?;
if span > stamp.abs() {
return Err(RoundingError::DurationExceedsTimestamp);
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing this check seems fine to me.

@@ -181,9 +181,6 @@ where
return Err(RoundingError::DurationExceedsLimit);
}
let stamp = naive.timestamp_nanos_opt().ok_or(RoundingError::TimestampExceedsLimit)?;
if span > stamp.abs() {
return Err(RoundingError::DurationExceedsTimestamp);
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you remove this check, I expect it will introduce a panic if the date is large and the duration is even larger. Say a date in the year 200.000 and rounding to a duration of 300.000 years.

Could you add a test for this case, and do something to avoid the panic?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't really work with such big timestamps here. It will return a TimestampExceedsLimit error:

An i64 with nanosecond precision can span a range of ~584 years. This function returns None on an out of range NaiveDateTime.
The dates that can be represented as nanoseconds are between 1677-09-21T00:12:43.145224192 and 2262-04-11T23:47:16.854775807.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, that's what I get when writing this without testing 😄. Any other errors with large durations such as 400 years that the previous check would have protected against?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't find any. Added a test for timestamps that are close to the min / max of nanosecond precision

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you 👍. @djc will also want to have a look, but it seems good to merge for me.

Copy link
Member

@djc djc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just needs a rebase.

This check is not necessary and prevented rounding and truncation
from working correctly on timestamps close to the Unix epoch.
@joroKr21
Copy link
Contributor Author

joroKr21 commented Feb 7, 2024

Looks like CI is failing on something unrelated

@pitdicker
Copy link
Collaborator

All CI failures are with the reason:

 error[E0635]: unknown feature `stdsimd`
  --> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ahash-0.7.7/src/lib.rs:33:42
   |
33 | #![cfg_attr(feature = "stdsimd", feature(stdsimd))]
   |                                          ^^^^^^^

Curious. In any case unrelated to your work.

@pitdicker
Copy link
Collaborator

We don't seem to be the only one thin-edge/thin-edge.io#2687.

@pitdicker pitdicker merged commit 5656a9e into chronotope:main Feb 7, 2024
30 of 35 checks passed
@joroKr21 joroKr21 deleted the bugfix/close-to-epoch branch February 7, 2024 11:29
@pitdicker
Copy link
Collaborator

Rkyv seems in the process of updating to hashbrown 0.14 (rkyv/rkyv@7b88320). Hashbrown 0.14 uses the updated ahash 0.8, which should build on the current nightly. Once a new version of rkyv is released our CI should be green again.

cc @djkoloski

@djkoloski
Copy link

rkyv 0.7 will not be updating to a newer version of hashbrown because it would be a server breaking change. 0.8 won't be out for a while either. I did create a branch of 0.7 that updates hashbrown yesterday (0.7-hashbrown-0.14) so you could change your dependency to a git dependency for nightly CI testing if that would help. Unfortunately I don't know of a better solution to this problem besides hashbrown releasing a fixed 0.12 version without stdsimd.

@djc
Copy link
Member

djc commented Feb 7, 2024

There's also a PR to request an update to ahash 0.7: tkaitchuck/aHash#201.

@pitdicker
Copy link
Collaborator

rkyv 0.7 will not be updating to a newer version of hashbrown because it would be a server breaking change. 0.8 won't be out for a while either.

Thank you for the explanation and replying here.

There's also a PR to request an update to ahash 0.7: tkaitchuck/aHash#201.

Nice, that seems to be the easier fix.

@pitdicker pitdicker mentioned this pull request Feb 10, 2024
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

Successfully merging this pull request may close these issues.

Truncating a timestamp close to EPOCH fails
4 participants