Unexpected aggregation time in FMRC (not equal to first time step and truncation error)

[marceloandrioni]

Hello, I have several monthly files aggregated in a FMRC with the usual code:

<featureCollection name="noaa_ww3_prodhind" featureType="FMRC" harvest="true" path="noaa/ww3/prodhind"> <collection spec="/home/opendap/datasets/noaa/ww3res05/**/multi_1.glo_30m.#yyyymm#\.nc"/> <update startup="true"/> <fmrcConfig regularize="false" datasetTypes="Best Files" /> </featureCollection>

each file contains three-hourly time steps with the time variable being a float with units "hours since 1970-01-01 00:00:00 UTC" with the first time step in the first file (200601) equal to 315576.0 (1970-01-01 00:00:00 UTC + 315576.0 hours = 2006-01-01 00:00:00).
But the new time created by FMRC has units "hours since 2006-01-01 00:01:00.000 UTC". I was wandering where does this extra minute (00:01:00.000) comes from? Just having a slightly non stardard time units would not be a problem, but this extra minute introduces a truncation error and a query in ncss results in:

time,latitude[unit="degrees_north"],longitude[unit="degrees_east"],hs[unit="m"]
2005-12-31T23:59:59.999Z,-25.0,-40.0,1.51
2006-01-01T02:59:59.999Z,-25.0,-40.0,1.59
2006-01-01T05:59:59.999Z,-25.0,-40.0,1.68
...

Is there a way of forcing FMRC to use a specific time:units or some other approach to correct this behavior? I am using thredds version 4.6.11.

If I join the monthly files in annual files using NCO (ncrcat) and change the collection spec to
<collection spec="/home/opendap/datasets/noaa/ww3res05/**/multi_1.glo_30m.#yyyy\.nc"/>
the aggregated time units becomes "hours since 2006-01-01 00:00:00.000 UTC" and the truncation error disappear.

Thank you very much.

[cofinoa]

@marceloandrioni,

the problem is in the expression to extract the date that you are using in the spec.
you must use upper case M for month, no lower case m which means minutes.
This error makes to interpret the 201601 date as year=2016 and minute=1, and the rest of elements of the date are interpreted as default, i.e. month and day with value 1 and time elements as 0 valued

...
  <collection spec="/home/opendap/datasets/noaa/ww3res05/**/multi_1.glo_30m.#yyyyMM#\.nc"/>
...

[marceloandrioni]

You are completely right @cofinoa, just replacing mm for MM did the trick. My bad for trying to write by memory instead of just copying from somewhere. I lost two days trying to correct this problem (writing the time as integer, changing the units to seconds, etc) and would probably waist more time if you hadn't figured out.

Thank you very much.