Wrong reftime in ODIMH5

[edigiacomo]

@tgastaldo reported and incorrect reftime for ODIMH5 file 000461.zip.

$ h5dump 000461.odimh5
...
      ATTRIBUTE "time" {
        DATATYPE  H5T_STRING {
           STRSIZE 5;
           STRPAD H5T_STR_NULLTERM;
           CSET H5T_CSET_ASCII;
           CTYPE H5T_C_S1;
        }
        DATASPACE  SCALAR
        DATA {
        (0): "0440"
        }
     }
...

But arkimet disagrees:

$ arki-scan --dump 000461.odimh5
Source: BLOB(odimh5,/home/edg/devel/arpae/arkimet/000461.odimh5:0+458556)
Origin: ODIMH5(16103, , )
Product: ODIMH5(PVOL, SCAN)
Level: ODIMH5(-0.2, 16)
Reftime: 2020-05-30T04:04:00Z
Area: ODIMH5(lat=42865900, lon=12800200, radius=0)
Task: DPC Standard Scan
Quantity: DBZH, QIND, VRAD
Note: [2020-06-04T09:01:33Z]Scanned from 000461.odimh5

I think that the problem is the missing seconds value in time: the scanner expects a time value with format %H%M%S (see https://github.com/ARPA-SIMC/arkimet/blob/master/conf/scan/odimh5.py#L24):

import datetime
datetime.datetime.strptime("202005300440", "%Y%m%d%H%M%S")
> datetime.datetime(2020, 5, 30, 4, 4)
datetime.datetime.strptime("202005300440", "%Y%m%d%H%M")
> datetime.datetime(2020, 5, 30, 4, 40)
datetime.datetime.strptime("20200530044000", "%Y%m%d%H%M%S")
> datetime.datetime(2020, 5, 30, 4, 40)

[dcesari]

For me it's correct, the bug can be closed, however all the travis builds fail, i feel it's for a different reason, but...

[brancomat]

all the travis builds fail

The related issue is #228.
However, I'd leave this issue open until a new arkimet version is released and deployed on the cineca server

[brancomat]

This should be fixed in v1.27-1, @dcesari could you update the cineca server to confirm it?

[edigiacomo]

Questa issue è stata chiusa per inattività. Nel caso in cui sia un argomento ancora rilevante, si prega di riaprirla con una motivazione che tenga conto delle modifiche applicate nel corso degli anni al progetto.