Ben,
The problem you mention with the 360 day calendar is a real one. The
problem is that there is no valid transformation between the 360-day
calendar and the Gregorian calendar. The 360-day calendar has no point
at which it is tied into history, and it is not defined relative to the
real Earth, but some theoretical planet that is closer to a theoretical
Sun than the real Earth is. You see this same problem with certain
geographic coordinate systems, particularly with vertical datums. There
are cases where you can't transform from one to another.
Your example nicely points out another aspect to the calendar attribute
value. If you wish to express the time coordinate values as timestamps
using a different calendar than the one named in the variable, then you
have to be sure that there is a valid transform. The transformation
still only has to be applied to the reference timestamp, but
transforming a 360-day calendar date into a Gregorian calendar date is
not valid. You can do some sort of adjustment to map your model (I
assume) times into something approximating a real-world calendar, but
you still don't have real-world dates when you are done. And it's fine
to do that if that is what you need to do. I could try and tell you what
you can or can't do as a data consumer all day long, but you are going
to do whatever it is you want and need to do to get your job done.
I think the calendars can make the "units" well-defined. In fact, apart
from the time system (UTC, TAI, etc) question, I'd say that the
calendars pretty well accomplish that already. We are used to being able
to convert quantities like gallons to liters or Kelvin to degrees
Celsius, and we assume that we should be able to convert any calendar to
any other calendar. The problem isn't in the calendars, it is in our
assumption that all of them are interchangeble. They aren't. Gregorian
and Julian dates are transformable because a common basis has been
defined. UTC and GPS times are transformable for the same reason.
360_day calendar dates are not transformable to anything else because
there is no common basis with anything else. The same goes for no_leap
and all_leap calendars.
Perhaps it would be good to add some words to the calendar section to
warn users about the fact that times in some calendars can't be
transformed into other calendars. Particularly, we could add warnings to
each of the different non-physical calendars pointing out that times in
these calendars can't be validly transformed into times in physical
calendars, and vice versa.
Grace and peace,
Jim
On 6/10/15 6:40 PM, Ben Hetland wrote:
> 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.")
>
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA?s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
o: +1 828 271 4900
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150611/b3480e1f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150611/b3480e1f/attachment-0001.png>
Received on Thu Jun 11 2015 - 07:14:31 BST
