#354: use new abs_before_epoch attribute if available for ClaimableBa… #394
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.
Problem: The Claimable Balance Claimant AbsBefore Predicate in API response has a formatted datetime string value which follows a custom extended format on top of ISO 8601 per the changes done in horizon API last year. By default ISO 8601 formatted dates support 4 digit years up to 9999. However, with this change in Horizon API, the custom formatted datetime strings for Predicate AbsBefore are based on a unix epoch value expressed as int64. This means it has a huge date range with a max of year 292277026596 into future and -292471206707 year back in past.
An example of value that could be in the json abs_before field:
"+39121901036-03-29T15:30:22Z"
The Java datetime libraries can't handle years this big, limit is 9 digits years or 999,999,999, so if AbsBefore Predicate datetime values with years greater than that are received from API, the Java SDK throws an error and stops parsing the API response.
Solution: use the new
abs_before_epoch
attribute added to the API via Horizon PR #4148, which will most likely be included to horizon API as of v2.14.0.closes #354