Add IsoDate::try_balance method #262
Closed
nekevss wants to merge 1 commit into
Closed
Conversation
nekevss
added
C-bug
Member
Author
|
Closing this in favor of #268 as it addresses this concern and then some. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR closes #250. By fixing the current panicking behavior of the test case.
For background, the current specification lists
BalanceISODateas fault tolerant. With the neri-schneider calculations, we ultimately don't support calculating a date with epoch days of 2^53 - 1. So instead of waiting for 12.2.6 CalendarDateAdd Step 3 to throw invalid epoch days (1,000,000,001 epoch days), this adds a newtry_balancemethod to throw invalid epoch days early when calculating the epoch days.To note, I have a feeling that there is most likely more changes to be made along this general line related to
daybeing represented by ani32vsi64, but I believe those would be linked to changes related to #189.