incorrect unit in temporal extent within getCapabilities document

[bjoern-reetz]

The time step of the temporal extent within the WMS capabilities document is rendered incorrectly when the time steps are not an integer number of hours.

Expected behaviour (step of PT15M):

<Dimension name="time" default="2022-02-14T03:00:00Z" units="ISO8601" multipleValues="0" nearestValue="0">
2022-02-14T03:00:00Z,2022-02-14T03:15:00Z/2022-02-15T03:45:00Z/PT15M
</Dimension>

Actual behaviour (step of PT0H):

<Dimension name="time" default="2022-02-14T03:00:00Z" units="ISO8601" multipleValues="0" nearestValue="0">
2022-02-14T03:00:00Z,2022-02-14T03:15:00Z/2022-02-15T03:45:00Z/PT0H
</Dimension>

Steps to reproduce:

• download and extract some total precipitation data of DWD's ICON-D2 model in regular_lat_lon grid format (which has a temporal resolution of 0.25 hours)
• launch SkinnyWMS with the data in it's SKINNYWMS_DATA_PATH, e.g. docker run --rm -p 5000:5000 --mount type=bind,source=$(pwd),target=/grib_data -e SKINNYWMS_DATA_PATH=/grib_data docker.io/ecmwf/skinnywms:latest
• look into the layer info within the WMS capabilities document, e.g. http://localhost:5000/wms?request=getCapabilities

The PT0H is most likely an artefact due to rendering 0.25 hours with "PT%d%s" % (step, unit) in datatypes.py.

[EduardRosert]

This issue is now resolved on develop branch. Please feel free to test.