Support LMST/LTST and other time systems

[bashbash]

efosse https://jira.jpl.nasa.gov/browse/AERIEQS-230 Moderate Surface missions on Mars require the ability to view activities within a given Martian Sol, which we all know is longer than an Earth day. Additionally, the unit of time spoke is typically Local Mean Solar Time (LMST) or Local True Solar Time (LTST). Both time bases are useful for Mission Planning.

I believe the values themselves can be retrieved from a SPICE Kernel but there is no way to have them be the default time unit display for an activity timeline.

[dandelany]

@AaronPlave is working on a first implementation of this feature. We've discussed a lot of different possibilities for implementing this over the past few months, so I wanted to capture a few of the important points that are driving the way we think about it:

• There is some variation in exactly how different missions calculate LMST. Even assuming they use the same formula, mission-specific SPICE kernels are needed to calculate it generally, since LMST is location-dependent. There are also occasionally other time systems that are used. For this reason, we think Aerie should support custom, user-provided time systems in general (of which LMST is one), rather than have Aerie itself implement LMST calculations.
• Custom time systems need to be able to tell Aerie how to convert their times to & from UTC, and how to format them as a string. They may need to rely on other files/libraries to do this, namely by referencing a SPICE kernel.
• Philosophically, it feels like the time system(s) and their used by a mission "should" be a part of the mission model - it is a property of the mission, and having it in the model would allow all other Aerie systems to make use of it.
  • However, the Aerie UI needs to be able to format & display time strings quickly, at "animation speed" - eg. to label the timeline cursor while the user is moving it around on the timeline, or to label the ticks on the timeline while it's being zoomed in and out.
  • Therefore, we don't think it's viable to only perform time conversions in the Aerie backend, since making an API call for every conversion would make the UI feel unacceptably slow. To support our current interactive time labeling, we need to be able to convert times on the frontend, in Javascript.
• While there are good use cases for being able to convert between time systems in other parts of Aerie, such as simulation and scheduling, most of the interest from users seems to be focused on just displaying time labels in the UI in LMST. Therefore, we've decided to focus on just the frontend/UI implementation of time systems for our first version, and consider integrating with the backend/mission model later.
• User research indicates that durations of time are usually (though not always) thought of by planners in terms of "earth time" (ie. UTC [or more precisely, "ET", Ephemeris time, since UTC leap seconds are not included]). Therefore our first implementation will focus on applying time systems to absolute time labels in the UI, not durations.

draft requirements to follow in next comment...

[dandelany]

Time Systems v1 Requirements

Based on meetings with @AaronPlave here are the requirements we decided on for v1:

1. Provide a Javascript interface which defines the structure of custom time system "adaptations", ie. JS files/bundles which implement LMST & other time systems. This should include at least format and parse functions, which convert a UTC DateTime to and from a string representing the time in the custom system.
2. Implement a way for users to include/upload their time system adaptations in their Aerie deployment. This could take the form of a UI which lets the user upload/configure time systems, or could be as simple as placing the time system adaptation files in a certain directory in your aerie deployment folder before running the Docker containers, depending on implementation decisions.
   1. This should take into account that a single adaptation may need multiple files, eg. a JS file + a SPICE kernel.
3. Provide a way for the user to specify their primary and secondary time systems, since we have labels which can show two time formats at once. For v1 this setting will apply to the entire deployment and affect all plans, rather than being plan-specific.
4. Update the Aerie plan timeline UI to use the configured primary/secondary time systems, if provided, to format any absolute time labels and tooltips in the UI (wherever it makes sense to do so).
5. Implement, likely in a separate repo, a set of Aerie "recommended" time system adaptations covering the most common use cases. This should include at least:
   1. An LMST implementation which uses a SPICE kernel + the timecraftjs library to convert to LMST.
   2. A local time zone conversion (eg. UTC -> PST)

Let me know if I missed anything!

[joswig]

@dandelany @AaronPlave how do you feel about adding the ability to customize the plan duration dispay in the new plan form?

"1 sol" mars surface plans are rarely exactly 24 mars hours, and rounding is usually preferred. 37 sol plans would also show as 38 days.

I think SI units for activity span durations are still the way to go for v1

[duranb]

@dandelany @AaronPlave how do you feel about adding the ability to customize the plan duration dispay in the new plan form?

"1 sol" mars surface plans are rarely exactly 24 mars hours, and rounding is usually preferred. 37 sol plans would also show as 38 days.

I think SI units for activity span durations are still the way to go for v1

@joswig What about anchor offsets?