Describe the bug
Hello,
I am currently trying to build a dataset using ERA5 data downloaded from the CDS.

The requirements are asking for tasmin/tasmax variables, which are not available in daily frequency. However, hourly tas is available, so I am attempting to use daily_statistics preprocessor to build them.

Here is a minimal version of the recipe I am using for CMORization:

hourly: &hourly_data
    - {exp: reanalysis-era5-single-levels,
    project: native6, timerange: 194001/194012, dataset: ERA5, version: v1, tier: 3, type: reanaly}
preprocessors:
  hourly_to_daily_max:
    daily_statistics:
      operator: max
diagnostics:
  CMORize:
    title: ERA5 CMORisation
    description: ERA5 CMORisation
    variables:
      tasmax:
        raw: t2m
        short_name: tasmax
        mip: AERhr
        additional_datasets: *hourly_data
        preprocessor: hourly_to_daily_max

It produces the expected resulting file. However, when attempting to load them in another recipe, this happens during the run:

esmvalcore.cmor.check.CMORCheckError: There were errors in variable tasmax:
 time: Frequency day does not match input data

I went on to investigate this, and it turns out that the time coordinate of the cube is responsible:

>>> import iris
>>> x = iris.load_cube("OBS_ERA5_reanaly_v1_day_tasmax_19400101-19401231.nc")
>>> xpts = x.coord('time').points
>>> xpts
[32871.5, 32872.5, ...., 33235.5, 33236.47916667]

The very last point is not strictly monotonically increasing, and by a difference that is above the accepted margin (i.e. 0.001) so the last loop of _check_time_coord from check.py finds it and raises the error.

Now, one normally fixes this kind of issues by tweaking the CMORizer, right ? But in the CMORization run, here is the order of preprocessors actions:

2023-05-05 09:47:43,434 UTC [219849] DEBUG   Running preprocessor step concatenate
2023-05-05 09:47:43,620 UTC [219849] DEBUG   Running preprocessor step cmor_check_metadata
2023-05-05 09:47:43,699 UTC [219849] DEBUG   Running preprocessor step clip_timerange
2023-05-05 09:47:43,799 UTC [219849] DEBUG   Running preprocessor step fix_data
2023-05-05 09:47:43,804 UTC [219849] DEBUG   Running preprocessor step cmor_check_data
2023-05-05 09:47:43,808 UTC [219849] DEBUG   Running preprocessor step add_supplementary_variables
2023-05-05 09:47:43,811 UTC [219849] DEBUG   Running preprocessor step daily_statistics
2023-05-05 09:47:50,756 UTC [219849] DEBUG   Running preprocessor step save

I want to point out here that the checks happens before the daily statistics, and does not go again through it. So I do not have a point where I could plug in a fix for time coordinate before it gets saved.

I thought about doing it in a script, however that means I have to load and realize the data of the cube because saving doesn't work with lazy data. Which sounds like a pretty heavy operation just to add 0.02 to the last point of the time coordinate.

Explanation

What I think is happening

>>> a = 33236.47916667
>>> b = 33236.5
>>> b - a
0.020833330003370065
>>> 1/48
0.020833333333333332

The shift is exactly of -1/2h. This is most likely caused by the checking and fixing of hourly data that happens before the daily_statistics is called, then is carried over until saving of the data.

I tried using this preprocessor instead, but it turns the time coord in a 'day_of_year' one, so not quite the expected result either.

    climate_statistics:
      operator: max
      period: day

So what I would like to know is if there is a known way to change frequency of a variable and save the resulting file in a compliant way with the tool ? Else I would like to know if it is possible to explicitly call cmor_check_metadata preprocessor in the recipe after daily_statistics ?

  hourly_to_daily_max:
    daily_statistics:
      operator: max
    cmor_check_metadata:

Redefining it like this, causes the run to fail because it is missing {'mip', 'cmor_table', 'frequency', 'short_name'} arguments, but I would like those to be passed over from the last operation.