What happened?
For mars requests / grib messages with an anoffset set, the CovJSON t axis is computed as forecast date + step, ignoring anoffset. However, anoffset shifts the reference time backward from the forecast cycle (date/time), and step is counted from that reference time, not from the forecast cycle itself. The encoder writes anoffset into mars:metadata but never applies it when computing t.
I compared against the GRIB validityDate/validityTime for an affected field and every CovJSON t value was later than the corresponding GRIB validity time by exactly anoffset hours, consistently across all steps.
mars:metadata correctly reports Forecast date and anoffset, so I imagine the fix should just be applying t = (Forecast date - anoffset) + step instead of t = Forecast date + step whenever anoffset is present.
What are the steps to reproduce the bug?
.
Version
develop
Platform (OS and architecture)
.
Relevant log output
Accompanying data
No response
Organisation
No response
What happened?
For mars requests / grib messages with an
anoffsetset, the CovJSONtaxis is computed asforecast date + step, ignoringanoffset. However,anoffsetshifts the reference time backward from the forecast cycle (date/time), andstepis counted from that reference time, not from the forecast cycle itself. The encoder writesanoffsetintomars:metadatabut never applies it when computingt.I compared against the GRIB validityDate/validityTime for an affected field and every CovJSON
tvalue was later than the corresponding GRIB validity time by exactlyanoffsethours, consistently across all steps.mars:metadatacorrectly reports Forecast date and anoffset, so I imagine the fix should just be applyingt = (Forecast date - anoffset) + stepinstead oft = Forecast date + stepwheneveranoffsetis present.What are the steps to reproduce the bug?
.
Version
develop
Platform (OS and architecture)
.
Relevant log output
Accompanying data
No response
Organisation
No response