Allow 100 nanosecond leeway in querying DAF files #348
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.
Summary
We've uncovered an edge case whereby the ephemeris time converted to UTC is a few dozen nanoseconds off of the UTC of exactly zero seconds. This is due to the greater precision in time management of hifitime compared to SPICE. As a direct cause, ANISE throws an error when trying to query the very first data point in a trajectory if it went through the UTC -> ET conversion in SPICE.
This PR adds a leeway of 100 ns when querying a trajectory (or any DAF file).
A test was added to the LRO BSP test
validate_gh_283_multi_barycenter_and_los
ensuring proper querying.This PR also prepares for the official release of v0.5. Note that there is NO change in file format for this version, and the format versioning is still set to
0.4
when building files.Architectural Changes
No change
New Features
No change
Improvements
No change
Bug Fixes
No change
Testing and validation
A test was added to the LRO BSP test
validate_gh_283_multi_barycenter_and_los
ensuring proper querying.Documentation
This PR does not primarily deal with documentation changes.