Add time & time bnds

[joshuatorrance]

Add time and time_bnds to the schema.

The current proposal requires the bounds to be name time_bnds. If this is relaxed to allow time_bounds then some further updates will be required. Could just use a regex to allow the alternative but this might permit a mix of the two. Compelling them to match will require additional some extra chicanery.

Contributes to #68
Closes #69

[blimlim]

I'm wondering if bounds should be required. For ESM1.6, the atmosphere, ocean, and ice all don't write a bounds attribute when the data is an instantaneous sample:

Atmosphere

	double time(time) ;
		time:axis = "T" ;
		time:units = "days since 0001-01-01 00:00" ;
		time:standard_name = "time" ;
		time:calendar = "proleptic_gregorian" ;

Ocean

	double time(time) ;
		time:long_name = "time" ;
		time:units = "days since 0001-01-01 00:00:00" ;
		time:axis = "T" ;
		time:calendar_type = "PROLEPTIC_GREGORIAN" ;
		time:calendar = "proleptic_gregorian" ;

Ice:

	double time(time) ;
		time:long_name = "model time" ;
		time:units = "days since 0001-01-01 00:00:00" ;
		time:calendar = "proleptic_gregorian" ;

I've created some small sample instantaneous outputs from ESM1.6 in /scratch/tm70/sw6175/access-esm/archive/test-snap-bounds-dev-preindustrial+concentrations-3874da77/output000/

[aidanheerdegen]

Seems like it shouldn't be if there are model outputs that don't include them for legitimate reasons.

[joshuatorrance]

CF doesn't require them for instantaneous data:

If cell boundaries are not provided (using the bounds attribute), an application can make no assumption about the location or extent of the cells. Without a boundary variable, it is unknown whether adjacent cells are contiguous, separated by a gap, or overlapping. If the data value pertains to the gridpoint alone, rather than to an interval, area or n-dimensional volume of non-zero size, it is recommended to indicate this with a cell_methods entry of point (Section 7.3, "Cell Methods"). In that case, the cell is irrelevant to the data and the bounds are arbitrary. Nonetheless, the bounds may still be included, for instance because the grid is shared by other data variables that pertain to cells, or to provide some indication of cells to generic applications for graphical purposes. A cell of truly zero size can be indicated by giving it coincident boundaries.

I'm personally a fan of that last option where instantaneous data has *_bnds with values equal to the coordinate's value. That would require upstream changes though so I may have to leave that for another day.

I can remove bounds from the required list.

[joshuatorrance]

I've created some small sample instantaneous outputs from ESM1.6 in /scratch/tm70/sw6175/access-esm/archive/test-snap-bounds-dev-preindustrial+concentrations-3874da77/output000/

Thanks for that! By-the-by, the atmosphere file doesn't have any cell_methods (maybe it's implied by the stash code?) and the ice file is missing the time: point that's in the ocean file.