The datum should always be interpreted according to the calendar system specified in the file.
That's how the time coordinate is handled in the output from every model that I've seen (which is at least a dozen), so I'd say do it that way just for the sake of backwards compatibility. But it's not clear to me that any alternative is even possible. What would it mean to say that my time coordinate uses a 360-day calendar, but that the start date is Jan 1, 1900 in the mixed gregorian calendar? Or worse, if the start date was Jan 31? It doesn't really make any sense. Likewise, units of months and years should also be interpreted according to the specified calendar. Using months and years as units is cautioned against in the spec, but if one were to do it, I'd say the expectation of nearly every end user and data provider would be that they would be in the same units as the calendar. Certainly, if you had a file of monthly data with a units attribute of "months" on the time variable, it would be obvious what was meant if the time coordinate went 1-2-3-4-5, and very confusing if it had some kind of non- integer spacing that corresponded to (days in month)*12/365.25... Cheers, --Seth On Sun, 9 Dec 2012 19:55:39 +0000 Jon Blower <[email protected]> wrote: > >Also, there are a couple of ambiguities in CF, which have also been brought up >before but not resolved. Time axes are recorded as a sequence of numbers >representing a certain number of intervals since a specified datum. The datum >is part of the units string of the time axis and is recorded in a kind of >pseudo-ISO format (e.g. "1970-1-1 0:0:0"). Should the datum always be >interpreted as a date/time in the mixed Gregorian/Julian calendar (as >specified by UDUNITS) or in the calendar system specified in the CF file >(which would probably be more sensible)? Also, should interval lengths (e.g. >months and years) be interpreted as the UDUNITS lengths (this is specified in >CF but is not always helpful) or should these vary by calendar (which is again >perhaps sensible, and some data providers do this)? _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
