Adapt tc_forecast to climada_python improved hdf5 IO

[emanuel-schmid]

Changes proposed in this PR:

• cast "time" values to float when reading bufr file in read_one_bufr_tc
  I suspect that with climada_python PR #735 time values are of dtype float when read from hdf5 (which makes sense too). But so far time has been an int.

This PR fixes failing of climada_petals.hazard.test.test_tc_tracks_forecast.TestECMWF.test_hdf5_io due to type differences in tc_track from bufr file and tc_read from hdf5

PR Author Checklist

• Read the Contribution Guide
• Correct target branch selected (if unsure, select develop)
• Descriptive pull request title added
• Source branch up-to-date with target branch
• Documentation updated
• Tests updated
• Tests passing
• No new linter issues
• Changelog updated

PR Reviewer Checklist

• Read the Contribution Guide
• CLIMADA Reviewer Checklist passed
• Tests passing
• No new linter issues

[tovogt]

Actually, you mean "time_step" instead of "time", right? In fact, "time_step" needs to be a float, otherwise interpolation of track data to sub-hourly resolution will make problems. This has not been introduced by CLIMADA-project/climada_python#735, but it was a problem before already. A similar issue is fixed in CLIMADA-project/climada_python#741, by the way, where I fix the problem that from_simulations_emanuel stores the "time_step" variable as integer type.

[tovogt]

As for the proposed changes: I think it's fine, but I would suggest to add a test for the dtype of "time_step" in https://github.com/CLIMADA-project/climada_petals/blob/cf6c0772c24fff6bcb92d2238cfb28427c5389cf/climada_petals/hazard/test/test_tc_tracks_forecast.py#L61C56-L62C59

[emanuel-schmid]

Many thanks! I'll add a a test.

[emanuel-schmid]

test added

[tovogt]

Great, thanks! Ready to be merged from my side.