Open tangobravo62 opened 3 years ago
This issue is postponed for the time being, as it would involve a design change for convenience issues.
Firstly, it would involve changing those attributes in raml files that accept time values in string format, including a pattern change and ensuring that all allowed patterns are processed correctly. Secondly, it would involve changing those attributes in raml files that accept time values in datetime-only format to accepting string formats, and accordingly adapt all REST services. For now, this was deemed too much effort for the resulting minor gain in convenience.
Currently most (if not all) of the time values are in fixed format (either with or without microseconds). From the API client perspective it might be helpful, if the same flexibility in parsing date-time values could be applied to the REST API as it is already in the CLI (where apart from the fixed orbit time format like
2020-04-08T00:00:00.000000
also values like2020-04-08
,2020-04-08T11:30+0200
or2020-04-08T11:30:45.123456Z
are allowed, with the missing parts defaulting to zero values and the UTC time zone, respectively).