Time Conductor should remember entered bounds when switching modes and time systems

[charlesh88]

From a conversation with @mudinthewater 3/12/2019. When switching mode (Fixed Time / Local UTC) and time system (ERT, SCET, etc.) the conductor's start and end bounds are constantly reset to defaults. This is not desirable; instead, the conductor should remember the last used bounds in the session per mode and time system permutation, and reinstate those when switching to that mode.

This is also related to #1472 which allows a user to store and recall date bounds.

[mudinthewater]

@charlesh88 It's a little more nuanced than that - some users would probably be okay with just this, but others want to be able to convert between time systems.

[mudinthewater]

I sent this idea to @deeptailor earlier, but there are known transitions between time types, and a few projects would like a seamless transition between them.

A good example of this is converting between J2000 and SCET, where J2000 has a known conversion to UTC, but isn't in UTC by itself. But if there was a way to define multiple time systems, and relate them with a function, then the eventual goal would be a seamless transition between them in the time conductor (This also happens frequently switching between SCET and SCLK views). I worked out an example of how I basically see this being done - you would define all the time types for a deployment as a spacecraft time system, and inside that spacecraft time system you could provide a conversion function for transitioning both directions between every time system that you want to define the transition for.

On view switch, the relevant conversion function would be used to convert the bounds of the time conductor. If no conversion function is defined, then we'd do the default behavior of remembering the previous time bound used rather than setting the default. Below is sort of how I see this working out, where all time systems are defined together, with a new function that would relate time systems that have a known conversion format.

function SCXTimeSystem() {
        return function (openmct) {
            openmct.telemetry.addFormat({
                 key: 'sclk-format',
                 format: function (number) {
                 return number+'';
                   },
                 parse: function (text) {
                 return Number(text);
                 },
                 validate: function (text) {
                 return !isNaN(text);
                 }
                  });
            openmct.time.addTimeSystem(
                {
                key: 'slck',
                name: 'SCLK',
                cssClass : 'icon-clock',
                timeFormat : 'sclk-format',
                durationFormat : 'sclk-format',
                isUTCBased : false
                }
                        );
                openmct.time.addTimeSystem(
                {
                key: 'scet',
                name: 'SCET',
                cssClass : 'icon-clock',
                timeFormat : 'utc',
                durationFormat : 'duration',
                isUTCBased : true
                }
                        );
                Openmct.time.relateTimeSystem(
                                {
                                 sourceFormat: ‘sclk-format’,
                                 destFormat: ‘utc’,
                                 conversion: function (number){
                                             return blah + blah whatever transition
                                                                }

                                });
                Openmct.time.relateTimeSystem(
                                {
                                 sourceFormat: ‘utc’,
                                 destFormat: ‘sclk-format’,
                                 conversion: function (number){
                                           return blah - blah whatever transition
                                                                }

                                  });
};

[akhenry]

Yeah it was implemented this way by design, due to the challenges of converting between time systems.

I like the idea of defining conversions via the API. We would need to do it in a way that also supports multi-mission environments, where the SCLK -> UTC conversion is per-spacecraft.

In the short term at least I think we could allow switching the time conductor between time systems that are based on UTC without too much ill-effect? Time systems have an isUTCBased flag on them which could be used for determining compatibility for this purpose.

[mudinthewater]

@akhenry yeah the SCLK->UTC transition is a particularly nasty one where we'd end up basically having to update a SLCK-SCET file on the deployment at the same rate that it's updated on the GDS.

Sadly that's the use-case that people want the most. The rest are more simple - GPS to UTC (ok this one actually sucks), J2000 to UTC, that sort of thing.

One potential hiccup with using the isUTCBased flag is that people like myself use it to cheat and just call anything that should appear with a calendar as UTC based. In reality I don't want to switch from Jan 1 2019 UTC to January 1 2019 in J2000. So there is some potential pain for those of us who did that down the road if you go that route.