step wrongly computed due to precision? for grib message with forecastTime in minutes

[cosunae]

What happened?

I have a grib file which I tried to archive in fdb. The units of the forecast time is in minutes (indicatorOfUnitForForecastTime). For most values of the forecast time the behaviour is as expected, I can archive and retrieve later on with the same request. However for the specific forecastTime of 260m, the archive works, but I can not find the record in FDB.
The reason seems to be that step is recorded in FDB as 4h19m59s, which does not match the 260m of the request. So It seems to be a precision issue.

grib_ls -p step,startStep,endStep,forecastTime,lengthOfTimeRange,shortName,param rea-l-i1efm00042000
260m 260m 260m 260 not_found ALB_RAD 500056

What are the steps to reproduce the bug?

In python, using the following request:
req={'step': '260m', 'date': 20120101, 'time': '0000', 'stream': 'enfo', 'class': 'od', 'expver': '0001', 'model': 'icon-ch1-eps', 'type': 'cf', 'levtype': 'sfc', 'param': 500056}

to archive the message with

fdb.archive(msg, req)

And then the message can not be retrieved with earthkitdata:

ekd.from_source("fdb", req, config=config, read_all=True)

Version

5.16

Platform (OS and architecture)

SUSE 15.4

Relevant log output

Inspecting the database with fdb-list, shows the different value of step:

{date=20120101,time=0000,stream=enfo,class=od,model=icon-ch1-eps,expver=0001,type=cf}{levtype=sfc}{step=4h19m59s,param=500056}, TocFieldLocation[uri=URI[scheme=file,name=rea-l-ch1_testdata/20120101:0000:enfo:od:icon-ch1-eps:0001:cf/sfc.20250720.222504.balfrin-ln002.991046523682818.data],offset=0,length=1390293,remapKey={}]

Accompanying data

No response

Organisation

MeteoSwiss

[danovaro]

Thanks @cosunae,
The issue is in the canonical representation of the step in metkit.
Fixed with this PR, released in metkit v. 1.14.1