On 2/23/2013 11:01 PM, Chris Barker - NOAA Federal wrote:
[...]
Largely agree with the points that Chris has made, but want to follow up
on one of them.
when you have non-standard calendars, the difficulty is compounded many
times over. How many seconds since 1970 is April 3, 2045 at 1:13 am in the
no-leap calendar? Are you sure? What if you could just put into your file
"2045-04-03T01:13:00" ?? Even rocket scientists can do that ;^)
good point here -- calendars are a nightmare!
It is a good point that translating between calendars is a nightmare.
But it *is not solved* by putting ISO strings into CF files. This
deceptively simple step merely _masks_ the problems of computability of
dates that_CF needs to address_. If one has two 10 year time series, say
1980-1990, of daily data -- one from a non-leap calendar model and
another from a Gregorian calendar model -- the two time series represent
the same time interval, but have differing numbers of points. What are
the rules for differencing the two time series? Use of ISO strings
contributes nothing to this. (In fact it leads down a rabbit hole that
has no easy exit.)
==> It is in the client libraries where the difficulties of fusing data
on different calendars needs to be solved -- not in the file encodings.
CF needs to make it simple for the "rocket scientists" to do this by
giving them tools that do it -- and do it right.
- Steve
P.S. At last we have a Python library development activity to
complement the Java libraries. Arguably a separate trac ticket is in
order to address time translations between different calendar axes.
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
