aportagain
commented
6 years ago Another option would be to explicitly use only the ISO8601 textual representation / formatting / encoding, but stick to the default CF calendar in both cases, unless the time variable's calendar attribute explicitly specifies a different calendar? netCDF best practices actually sounds kinda like that: https://www.unidata.ucar.edu/software/netcdf/docs/BestPractices.html
So something like: "Time data should be expressed as numeric values relative to a start time as in CF-conventions OR as strings formatted according to ISO8601. In both cases, the default calendar is the mixed Gregorian/Julian calendar, which is also used by default in CF (in contrast to the full ISO8601 specification, which uses the proleptic Gregorian calendar; see ISO8601 section 4.3.2.1 and CF sections 4.4.1)."?
A related question is then what to do with units for ISO8601 strings. CF explicitly requires time coordinate variables to have units, which conversely allows us to use the units to identify time coordinate variables... can we get along without this, or would we then need to specify that we can have only one time coordinate variable, and that is always called "time"?
The default calendar in CF is a "mixed Gregorian/Julian calendar as defined by Udunits" (identified as "gregorian" or "standard" in the calendar attribute). ISO8601 uses the "Gregorian" calendar, defined in a way which I think corresponds to the "proleptic_gregorian" calendar in CF. This may cause differences for dates before 1582-10-15, and possibly also for climatology data with time units relative to 0-1-1 (CF doesn't recommend this, but allows it for compatibility with COARDS).
Maybe we could add to section 2.3.4 something like: "Note that ISO8601 uses the Gregorian calendar, while CF by default uses a mixed Gregorian/Julian calendar. This may lead to differences in interpretation for dates before 1582-10-15 or climatological data specified relative to year zero. See ISO8601 section 4.3.2.1 and CF sections 4.4.1 and 7.4."