time dim values of interval; start middle midpoint end

[chrisdane]

Question

Hi

Should the time dim values be at the beginning, middle, or end of the interval they represent?

Example 7.1 of the current CF version (1.12) reads

The instant time(i) should be contained within the interval, or be at one end of it.

In example 7.5, a time series file with 5 time steps representing 12-hourly statistics has the time dim values

  time = 0., 12., 24., 36., 48.;

and below the example this info is given:

Note that in this example the time axis values coincide with the end of each interval. It is sometimes desirable, however, to use the midpoint of intervals as coordinate values for variables that are representative of an interval.

In example 7.9, a climatological file with 4 time steps representing seasonal means of MAM, JJA, SON, and DJF has the time dim values

  time="1960-4-16", "1960-7-16", "1960-10-16", "1961-1-16" ;

In example 7.10, a climatological file with 3 time steps representing decadal means of 1961-1970, 1971-1980, and 1981-1990 has the time dim values

  time="1965-1-15", "1975-1-15", "1985-1-15" ;

In example 7.11, a climatological file with 24 time steps representing hourly averages over all days of April 1997 has the time dim values

  time="1997-4-1 0:30", "1997-4-1 1:30", ... "1997-4-1 23:30" ;

Hence, in many but not all examples the middle of the temporal interval is used, and I could not find a clear recommendation.

Note that e.g. cdo uses the middle by default:

cdo -h timmean
...
    The time of outfile is determined by the time in the middle of all contributing timesteps of infile.
    This can be change with the CDO option --timestat_date <first|middle|last>.

Thanks a lot and cheers,
Chris

[sethmcg]

CF doesn't mandate where the time coordinate sits relative to the interval, so the user is free to choose.

However, I would argue that best practice is to put it in the middle of the interval. In my experience, when the time it at one end of the interval, it's easy to get confused. If you have a time interval covering the year 1990 and you put the coordinate at the end, then it's at midnight on New Year's Eve, which is ambiguous as to which year it belongs to. If the time coordinate is instead at the beginning of July, you know exactly which year it belongs to.

[ChrisBarker-NOAA]

Backward compatibility is key, but CF could make a clear recommendation, and have the examples represent best practices.

We could also have examples of legal, but not "best practices", but ideally they would be marked as such.

I think we should keep in
mind that many people follow examples, rather than reading the spec and applying it. Which is why examples should be best practices if not clearly marked as being a special case.

[sethmcg]

I would support that.

[chrisdane]

Thanks all, can be closed from my side.

[taylor13]

I would note that "accumulations" or "sums", unlike "means" have often used the end of the period, not the middle as the coordinate. So daily precipitation amount is sometimes marked by midnight of that day, not noon. More generally, for some other cell_methods (e.g., median, maximum, minimum), additional information would be conveyed to users if the time when the median, maximum, minimum ... occurred were assigned to the coordinate value. So, if we make any sort of recommendation, we should make it a weak one and constrain it to only certain cell_methods. The current guidance is:

If cell boundaries are provided, it is recommended that each gridpoint should lie somewhere within or upon the boundaries of its own cell.

This could perhaps be strengthened along the lines "If cell boundaries are provided, it is recommended that each gridpoint should lie somewhere within or upon the boundaries of its own cell. For most cell_methods, a common practice is to defined the coordinate value as halfway between its bounds, but this is not mandated."

[ChrisBarker-NOAA]

@taylor13 : I like that language.

However, a lot of folks don't provide cell boundaries -- maybe we should have advice for them as well?

[JonathanGregory]

This is a sensible question, which has been asked before, and it's included in the FAQ. There is also some relevant text in the conventions document. Section 1.4 "Overview" says

Because both the [NUG] and [COARDS] define coordinate variables but not cells or bounds, many applications assume that gridpoints are always located at the centers of their cells. This assumption does not hold in CF. If bounds are not provided, the location of the gridpoint within the cell is undefined, and nothing can be assumed about the location and extent of the cell.

and Section 7.1 "Cell boundaries" says

If cell boundaries are provided, it is recommended that each gridpoint should lie somewhere within or upon the boundaries of its own cell.

We could certainly provide a more definite recommendation, for cases where the data-writer has no reason to make a particular choice. It would be logical to put this recommendation in Sect 7.1, I think. It could be referred to from Example 7.1 (in Sect 7.1.1), which Chris cites at the top of this issue.