Time offset format is inconsistent between plan JSON and Aerie UI

[parkerabercrombie]

The Aerie UI (and GraphQL response) displays start offests as hh:mm:ss.sss. Aerie always shows number of hours, even if the offset is more than 24 hrs. However, when I download a plan using the aerie-cli the offset is represented as "D days, hh:mm:ss.sss". For example "start_offset": "2 days, 0:59:59.897000", where as in the Aerie GUI, it's 48:59:59.897.

This difference in format makes it difficult to match up times in the plan JSON file with activities in the Aeri/e UI. We should use the same offset format as in Aerie.

[cartermak]

I'd be happy to support an audit of time formats with some more intentional design decisions like this. I'll just note that this would be another breaking change to the plan JSON format; the current time/duration string formats are based on standard string-ify methods from Python libraries, so any other tools that interact with JSON plans would need to update their de/serialization to handle a custom format.

[parkerabercrombie]

I think it would be worth a breaking change to standardize with the Aerie time format. Let's talk about the potential impact to other tools.

[cartermak]

Adding some notes here in support of the Aerie Plan JSON format effort:

• Aerie-CLI contains several methods for (de)serializing duration values: https://github.com/NASA-AMMOS/aerie-cli/blob/develop/src/aerie_cli/utils/serialization.py
• These methods handle three different formats: 1) Postgres interval output for downloading from Hasura/Postgres, Postgres interval input for uploading to Hasura/Postgres, and the Python timedelta standard format for Plan JSON.
• I endorse moving the Plan JSON format away from the Python timedelta format and towards whatever the Aerie UI uses, for consistency.
• This unit test contains examples of the different time formats being converted around: https://github.com/NASA-AMMOS/aerie-cli/blob/develop/tests/unit_tests/test_utils.py