Fix 'ahi_hsd' reader crashing when 'observation_timeline' was invalid

[simonrp84]

If an AHI data file contains fill value for the 'observation_timeline' property then the ahi_hsd reader crashes when it tried to round the observation times across segments.
This PR checks whether the timeline is valid and only performs rounding if it is. If invalid, no rounding is done and a warning is shown to the user.

[sfinkens]

Thanks for the fix! Just one comment regarding readability. Would you mind adding a test for this?

[codecov]

Codecov Report

Merging #2107 (03a62ef) into main (16b76bf) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #2107   +/-   ##
=======================================
  Coverage   93.95%   93.96%           
=======================================
  Files         283      283           
  Lines       42881    42901   +20     
=======================================
+ Hits        40290    40310   +20     
  Misses       2591     2591           

Flag	Coverage Δ
behaviourtests	4.76% <0.00%> (-0.01%)	⬇️
unittests	94.51% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
satpy/readers/ahi_hsd.py	97.50% <100.00%> (+0.07%)	⬆️
satpy/tests/reader_tests/test_ahi_hsd.py	99.61% <100.00%> (+0.01%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 16b76bf...03a62ef. Read the comment docs.

[coveralls]

Coverage increased (+0.003%) to 94.455% when pulling 03a62ef on simonrp84:him_fix_obstime into 16b76bf on pytroll:main.

[sfinkens]

Thanks a lot for adding the tests! Just one tiny comment :)

[djhoese]

Does removing the np.array reflect what the real code is getting? At least in the NetCDF/HDF5 readers these libraries have cases where they return a scalar array of a single string and we have to do extra work to make sure they are converted to plain strings correctly. If you kept the original np.array usage and converted 300 to a string would that imitate the files well enough?

[simonrp84]

Yes, it does: While debugging I had some print statements inside the ahi_hsd.py file and they showed that there's no numpy arrays for these values, they're all simple strings or floats.

[simonrp84]

Tests are failing but I think the failures are not to do with the changes here.

[djhoese]

The MacOS job seems to be a hiccup, the other one is the unstable environment which is failing because of changes in dask that are incompatible with xarray. We can track the dask/xarray issue at pydata/xarray#6578

I've restarted the MacOS job.

[simonrp84]

Thanks, seems to have worked now

[sfinkens]

LGTM!