Convert `time_range` to ISO format

[jkrasting]

Is your feature request related to a problem? Please describe.
GFDL and CESM have different levels of detail when encoding date/time information in their model output file paths. Since the catalog builder infers date ranges from the filenames, this produces unpredictable results.

Describe the solution you'd like
We would benefit from:

1. Different time inference rules for GFDL and CESM output
2. Standardizing the character output to be in ISO format and separated by a comma e.g. T0,T1

Describe alternatives you've considered
I do something hacky in the notebook template and it would be much better if it we also a predictable ISO format

Additional context
Add any other context or screenshots about the feature request here.

@aradhakrishnanGFDL @bitterbark @emaroon

[ceblanton]

Thanks @jkrasting ! We're all for ISO datetime standards, all things considered, especially ISO 8601.

The existing date-time strings are the timeseries filename string outputted by FRE postprocessing.

Do you have a specific proposal replacement? e.g. a 5-year monthly timeseries looks like:

000101-000512

Would the ISO format be:

00010101T000Z,00051231T2359Z ?

Should the start and stop dates be in one CV item or two? Two might be a little cleaner, as the catalogs are in CSV format themselves.

[aradhakrishnanGFDL]

@ceblanton 00010101T0000Z-00051231T2359Z or including seconds T000000Z?
What do you propose so that GFDL, NCAR/CESM, MDTF can use existing python utilities for the conversion to use a standard representation?

[bitterbark]

I'd love to hear of an existing utility. We can probably get CESM timeseries files compliant with the format, because the ADF is putting some sort of date string on them already.

[ceblanton]

@jkrasting, @aradhakrishnanGFDL , @bitterbark , and @ilaflott ,

We desire the time range of a NetCDF file to be specified in a clear, unambiguous, and standard format. What about using the CMIP/CMOR/ESGF date-range conventions exactly, since they have been unchanged since CMIP5 and and CMIP/CMOR/ESGF and intake-esm share culture and tools ?

It has the benefit of standardization and familiarity but the disadvantage of not being exactly ISO8601 (possibly).

Example:

• Ten years of annual: 2000-2009
• Ten years of monthly: 200001-200912
• Ten years of daily: 20000101-20091231

From CMIP6_global_attributes_filenames_CVs, around page 14 "filename conventions":

The <time_range> is a string generated consistent with the following:
If frequency = “fx” then
              	<time_range>=””
else
<time_range> = N1-N2<suffix> where N1 and N2 are integers of the form ‘yyyy[MM[dd[hh[mm[ss]]]]]’ (expressed as a string, where where ‘yyyy’, ‘MM’, ‘dd’, ‘hh’ ‘mm’ and ‘ss’ are integer year, month, day, hour, minute, and second, respectively)
endif
 
where <suffix> is defined as follows:
if the variable identified by variable_id has a time dimension with a “climatology” attribute then
suffix = “-clim”
else
suffix = “”
endif
 
and where the precision of the time_range strings is determined by the “frequency” global attribute as specified in Table 2.

Frequency	Precision of time label	Notes
yr, dec, yrPt	“yyyy”	Label with the years recorded in the  first and last coordinate values.
mon, monC	“yyyyMM”	For “mon”, label with the months recorded in the  first and last coordinate values; for “monC” label with the first and last months contributing to the climatology.
day	“yyyyMMdd”	Label with the days recorded in the  first and last coordinate values.
6hr, 3hr, 1hr, 1hrCM, 6hrPt, 3hrPt, 1hrPt	“yyyyMMddhhmm”	Label 1hrCM files with the beginning of the first hour and the end of the last hour contributing to climatology (rounded to the nearest minute); for other frequencies in this category, label with the first and last time-coordinate values (rounded to the nearest minute).
subhrPt	“yyyyMMddhhmmss”	Label with the first and last time-coordinate values (rounded to the nearest second)
fx	Omit time label	This frequency applies to variables that are independent of time (“fixed”).

[jkrasting]

@ceblanton , I think this is a fine option as well. I have a routine that can take CMOR date range conventions and do the “last mile” conversion to datetime objects if needed:

• process_time_string()