need to clarify corner cases for ISO8601 time values

[jvandegriff]

We realized that some values we've been allowing for ISO8601 times are no longer being accepted by common parsers because they are at the edges of what ISO8601 allows, and are so probably not valid time strings.

See this issue on the python client: hapi-server/client-python#76

Not valid ISO8601: YYYY-MM-DDZ (Z is only valid when there is a time value in addition to a date value)

The schema has regex values which need updating, and there's a ticket for that:
hapi-server/data-specification-schema#18

Action items:

• documentation needs a note about evolving interpretations of ISO8601.
• schema needs updating (regex values for acceptable time strings need changing to exclude the newly bogus values)
• verifier needs updating - it will pick this up through an updated schema

Have a list of OK and not OK examples.

Bad values:

2025-03-04T.Z
2025-03-04Z

OK values:

YYYY-MM-DDT00Z
YYYY-MM-DD  (implies time zone is unknown, so you don't know when it is on that day - do we need to specify a HAPI default for this?)

Other things to clarify: if you leave off any time value, we assume it is in the middle of the day

[VoyagerPWS]

How would you designate the date of Explorer 1 launch? It was 1958-01-31 local time, but 1958-02-01 GMT. How to you specify a date is UTC if not with the Z.

[VoyagerPWS]

Also, if a truncated date/time doesn't refer to the beginning of the interval, I'm afraid all sorts of inconsistencies arise.