Currently, the time_coverage_start and time_coverage_end attributes of the output dataset are produced by the combine_netcdf_time_limits method, which calculates them as the minimum and maximum, respectively, of the corresponding attributes in the set of NetCDF files downloaded from the CDS API. Unfortunately, both the syntax and semantics of the values returned by the CDS API appears to be inconsistent. In one soil moisture test, the time_coverage_start is 2014-12-31T12:00:00Z (corresponding to the start of the requested time period); in another, with different parameters, time_coverage_start is 19910805T000000Z -- not only is the syntax here a different dialect of ISO-8601, but the actual time represented has no relation to the requested period -- rather, it seems to be the coverage start for the entire product!
In principle, it would not be difficult for the CDS store to recalculate the values of time_coverage_start and time_coverage_end directly from the data itself. The desired semantics are presumably the first of those mentioned above (i.e. covering the requested period rather than the whole product), but we should document this officially, and also decide:
The syntax/format for these attributes.
Whether the attributes are necessary at all. They don't seem to be part of the CF conventions. If they're not needed, the simplest solution would be to erase them.
Currently, the
time_coverage_startandtime_coverage_endattributes of the output dataset are produced by thecombine_netcdf_time_limitsmethod, which calculates them as the minimum and maximum, respectively, of the corresponding attributes in the set of NetCDF files downloaded from the CDS API. Unfortunately, both the syntax and semantics of the values returned by the CDS API appears to be inconsistent. In one soil moisture test, thetime_coverage_startis2014-12-31T12:00:00Z(corresponding to the start of the requested time period); in another, with different parameters,time_coverage_startis19910805T000000Z-- not only is the syntax here a different dialect of ISO-8601, but the actual time represented has no relation to the requested period -- rather, it seems to be the coverage start for the entire product!In principle, it would not be difficult for the CDS store to recalculate the values of
time_coverage_startandtime_coverage_enddirectly from the data itself. The desired semantics are presumably the first of those mentioned above (i.e. covering the requested period rather than the whole product), but we should document this officially, and also decide: