Jim,
You wrote:
> As a data consumer, all I have to do is convert the reference time from the stated calendar to my desired calender, then use that as the basis for producing timestamps from the elapsed times in the variable (using the correct set of time functions, of course). Expressing the elapsed times as timestamps in one calendar and then converting those timestamps to another is another way that you could do it, but one which adds unneeded steps. I don't see any reason to assume that data consumers would work in one particular way.
Suppose then, for the sake of argument and since somebody already introduced the concept of a 360-day model calendar, that I have this model that produces data in "days" since 2012-01-01 of this simplified calendar (where every month also has 30 days). For my convenience as the data producer I then indicate that kind of calendar in the NetCDF, and "days since" makes sense because that is also my internal time axis coordinates. The dates can perhaps be interpreted such that they are just to be roughly the same date in the Gregorian calendar. So when I get to 2013-01-01 in my model I just store the time as 360.0 "days".
Turning to the consumer side, it might be simple in my own little viewer tool that just uses the "simplistic" calendar calculations to show monthly values as, say, 2012/dec and 2013/jan for the 330 and 360 day entries respectively. However, another reader might have implemented more accurate calendar support, and it correctly converts the ref. timestamp from 360-d into gregorian. If the reader now gives no further thought to just that peculiar "days" unit, but just adds the day counts on the Gregorian timescale, then the aforementioned two data values will end up at 2012/nov and 2012/dec instead.
OK, so if it was a bad idea to do it that way, should the reader just scale the time values by eg. (365.2425/360.0)? Still my 360-value would become 2012-12-31T05:49 because it was a leap year. Still other conversions could be weird if we have models where every .0 time is at midnight and the .5 fractions are at noon, because now they will just end up at all times of day on the Gregorian scale...
The core of the problem here, as with the leap seconds, is that either the length of the units are not the same in all reference systems (such as the days vs months vs year above), or they are not really constant or have discontinuies across two reference systems (here: the calendars). The latter has already been well illustrated in this discussion thread regarding the leap seconds, I think, so further elaborations appear unnecessary.
> The reference timestamp in the units attribute is what anchors the elapsed time values into history.
Yes.
> That's all that is needed.
Only if the "units" are well-defined (see above), which unfortunately in the case of calendars seems not to be the case.
> If you modify a time variable by giving the calendar attribute a new value and changing the timestamp in the units attribute from the original calendar to the new calendar, the contents of the altered time variable will still refer to the same points in history.
Not if it had been converted into "elapsed time" using the inherent assumptions tied with one calendar system, and then we use different assumptions from the new calendar system to back-convert into a timestamp. Again a "hidden" scaling/ modification happens when switching the "system". I suppose other things than time/calendar are affected by this too, like monetary values involving two or more currencies for instance. ("Which reference rate.")
--
-+-Ben-+-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: CicsLogoTiny.png
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150610/f3db368d/attachment-0001.png>
Received on Wed Jun 10 2015 - 16:40:13 BST
