ORD validator fails when `start_time`/`end_time` used instead of `datetime`

[ritvje]

For the datetime fields, the JSON schema requires either datetime or both start_datetime and end_datetime. But if the second option is used, the validator fails when printing the success message due to the missing properties/datetime field.

Schemas: ['./schemas/openradardata-spec.json', 'data/202507070500_composite_cappi_600_acrr24h_finradfast_qc.json']
Read Openradar schema: ./schemas/openradardata-spec.json
Read msg: data/202507070500_composite_cappi_600_acrr24h_finradfast_qc.json
Traceback (most recent call last):
  File "/home/ritvanen/Documents/PAK_koodit/openradardata-validator/ord_validator.py", line 35, in <module>
    print("Validation OK: {0} {1}\t{2}\t{3}".format(msg["properties"]["datetime"], msg["properties"]["platform"], msg["properties"]["level"], msg["properties"]["content"]["standard_name"]))
                                                    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 'datetime'

Example file: 202507070500_composite_cappi_600_acrr24h_finradfast_qc.json

[ritvje]

Additionally, the ORD validator script validates the JSON as correct when the datetime field is missing but start_time and end_time are present. But the actual API endpoint does not accept the file when datetime is missing.

[istvans-mn]

For the datetime fields, the JSON schema requires either datetime or both start_datetime and end_datetime. But if the second option is used, the validator fails when printing the success message due to the missing properties/datetime field.

Fixed 646b917

[istvans-mn]

Additionally, the ORD validator script validates the JSON as correct when the datetime field is missing but start_time and end_time are present. But the actual API endpoint does not accept the file when datetime is missing.

E-SOH issue created. EUMETNET/e-soh#269

[istvans-mn]

Fixed:
here: https://github.com/EUMETNET/openradardata/commit/f4087c2a970cf4d983088ad8a108759e5f94c855
and here: https://github.com/EUMETNET/openradardata/commit/f2a8efd3d7df43a1c63181f77db2d9c66c89675b
Please test the new (test) instance: 64.225.128.20