Local solar time computations

[ChristopherRabotin]

High level description

Note: only the high level description needs to be filled out to report an issue or to request a new feature.

New feature

If this is a new feature, describe the need you have either with use cases or examples. If this is a bug report, file a bug report instead.

Requirements

• ANISE shall provide a function equivalent to et2lst that takes an ephemeris epoch et and a longitude as input arguments.
• The et2lst function shall return the local solar time at the specified longitude for the given epoch.
• The et2lst function shall be based on the SPICE implementation and provide the same results.
• The et2lst function shall take into account any applicable leap seconds in the computation of the local solar time.
• The et2lst function shall handle inputs in a range of valid values, including dates beyond the valid range of SPICE.
• The et2lst function shall return an error if the input arguments are invalid or if there is a problem with the computation.
• The opposite function (equivalent to lst2et) shall take as input the local solar time, the longitude of the object, and the body on which the object is located.
• The function shall return the corresponding ephemeris epoch et or local solar time.
• The function shall handle cases where the input local solar time is outside of the range [0, 86400] seconds.
• The function shall handle cases where the input longitude is outside of the range [-180, 180] degrees.
• The function shall handle cases where the input body is not recognized.

Test plans

For the et2lst function equivalent, test cases should include providing a variety of epoch times and longitudes to ensure that the resulting local solar time is correct. This can be verified by comparing the output of the function to expected values or by comparing it to the output of the lst2et function when provided with the same input.

For the lst2et function equivalent, test cases should include providing a variety of local solar times and longitudes to ensure that the resulting epoch time is correct. This can be verified by comparing the output of the function to expected values or by comparing it to the output of the et2lst function when provided with the same input.

Design

This is the design section. Each subsection has its own subsection in the quality assurance document.

Algorithm demonstration

If this issue requires a change in an algorithm, it should be described here. This algorithm should be described thoroughly enough to be used as documentation. This section may also simply refer to an algorithm in the literature or in another piece of software that has been validated. The quality of that reference will be determined case by case.

API definition

Define how the ANISE APIs will be affect by this: what are new functions available, do any previous function change their definition, why call these functions by that name, etc.

High level architecture

Document, discuss, and optionally upload design diagram into this section.

Detailed design

The detailed design *will be used in the documentation of how ANISE works.

Feel free to fill out additional QA sections here, but these will typically be determined during the development, including the release in which this issue will be tackled.